dashmap | Blazing fast concurrent HashMap for Rust | Reactive Programming library

Your closure unconditionally creates a new inner hashmap each time, which it uses as value in the outer hashmap. However, it inserts it into the outer hashmap under the same key (route.to_string()) all three times, which results in each insert overwriting the previous one(s).

You need to implement a logic that will create a new inner hashmap only if one is missing under that key, otherwise look up the existing one. Then it should insert the value into the inner hashmap, either the freshly created one, or the one looked up. In Rust this is conveniently done using the entry API:

None of the examples will produce a deadlock.

From the documentation:

insert(): Inserts a key and a value into the map. Returns the old value associated with the key if there was one.
Locking behaviour: May deadlock if called when holding any sort of reference into the map.

iter(): Creates an iterator over a DashMap yielding immutable references.
Locking behaviour: May deadlock if called when holding a mutable reference into the map.

get_mut(): Get a mutable reference to an entry in the map
Locking behaviour: May deadlock if called when holding any sort of reference into the map.

Explanation:

In your first two examples, only iter() is used, so as long as no other operations that take mutable references into the maps are used, there will be no deadlocks.

In your third example, DashMap b is only ever used with iter() again, so no deadlocks there. For DashMap a there are two possible execution flows:

1. If thread 1 reaches a.iter() first, then thread 2 will have to wait at a.get_mut(key), but once thread 1 has finished iterating over a thread 2 will be able to continue, so there will be no deadlock.
2. If thread 2 reaches a.get_mut(key) first, then thread 1 will have to wait at a.iter() but once thread 2 has finished it will be able to continue and there will be no deadlock.

Additional questions:

Inserting into a DashMap when iterating over it in the same thread will produce a deadlock.

Example:

What I ended up doing here was using channels, but I was able to find a way to avoid needing to recreate the API of StateMachines.

The technique is to use channels to pass a closure to a dedicated thread the StateMachines instances live on which accepts a &mut StateMachines argument, and sends the response back down a different channel, which lives on the stack while the access is happening.

Here is a playground implementing the key part https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e07972b928d0f0b7680b1e5a988dae84

The details of instantiating the machines on their dedicated thread are elided.