[nanomsg] Re: Inproc latency and programming challenge!

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Wed, 30 Jan 2013 06:49:07 +0100

On 29/01/13 20:47, Paul Colomiets wrote:

1. nn_send(A)
2. lock mutex A

3. nn_send(B)
4. lock mutex B
5. message is written to a shared pipe
6. lock mutex A<-------- deadlock happens here
7. signal A's condition variable
etc.


I think it's possible to do "trylock" instead locking in step 6, in
case lock is contended return some error code (e.g. EBUSY), propagate
it all the way down to nn_sock_send, then unlock the socket and try
again immediately. This will probably improve the benchmark, but may
lead to live-locks in practice. What do you think about this strategy?

In theory.

In practice it's dauntingly complex. First, there can be multiple destinations for the message so you would have to keep *list* of mutexes to be re-tried.

Even worse, once you unlock the original socket, another nn_send() call may be executed by the user and you are left with two lingering messages. Ultimately you have to implement user-space queueing of messages etc.

Martin


Other related posts: