...
After each worker thread issues its replication Rpcs, it will invoke `getThreadId()` to get a handle to the current thread. It will then map each of the n replication Rpc Ids to the thread ID in a map which is visible to the dispatch thread.
Finally, it will call `custom_wait`, which puts itself into a set of threads that are simply waiting for the application to wake them up.
When the dispatch thread receives a response to an Rpc, it will check the map and call `wakeup` on the value associated with the Rpc ID.
This approach appears to represent what we want, but there are several possible races between the dispatch thread's lookup and wakeup, and the worker thread's insertion into the map and then calling custom_wait.
The only current way we can think of for ensuring safety is to wrap most of the operations in a lock, and releasing the lock inside custom_wait the same way that a condition variable would, but this raises complexity and scalability concerns.
How is Idea 3 different from using a map to condition variables and then calling signal on the condition variables?
...