To sum up the problem, all threads would try to send first and block, thereby causing a deadlock since no other thread will be able to receive while blocking. To fix it, we can divide the threads in half (say like evens and odds) and have one half send first, while the other half receives first.

^yup. I'm curious - what's the point of a synchronous send? Synchronous receive definitely makes sense, but blocking on someone receiving your message when you could essentially leave it in a queue for them to pick up later seems like it's an unnecessary synchronization step.

@mziv Synchronous send could be useful when you want to make sure the recipient has actually received your message

@potato I'm guessing that @mziv wants to know an example of where this actually might come in handy.

Another approach that we could examine in addition to that put forward by @Claire would be just to limit the number of threads that could be waiting for synchronous send/receive using something like a Semaphore.

@mziv I think that for some connections you wouldn't want to overwhelm the receiving end with sends and thus you would prefer to wait until the receiver got your message before sending anymore messages. That could be implemented using asynchronous send thou, so I think it just depends on the task you are doing. If you are in a need of a synchronous send you wouldn't want to write extra code to use an asynchronous send when you have a function that does the same job for you.

To build off of what @marwan said, asynchronous sending is only useful when you have extra work to do (just like asynchronous clothes-washing is only useful if you have better things to do), but this is not always the case. For instance, a lot of web servers handle clients by spinning off threads for each client. In this case, the only a thread has only one responsibility, so it might execute a blocking send and then yield the CPU to another thread. In node.js servers where there is only one thread servicing every client, then asynchronous sends are a must.