...
For every Rpc response received, every worker thread will waste work by waking up to check if the response was for them.
Idea 3:
...
User-Controlled Thread Blocking and Unblocking
After each worker thread issues its replication Rpcs, it will invoke `getThreadId()` to get a handle to the current thread. It will then map store the threadId into each of the n replication Rpc Ids to the thread ID in a map which is visible to the dispatch threadRpcs.
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`block`, which will remove it the run queue and allow other threads to run.
When the dispatch thread receives a response to an Rpc, it will check the map look up the threadId in the Rpc 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, which will put it back onto a run queue.
How is Idea 3 different from using a map to condition variables and then calling signal on the condition variables?
...