[nanomsg] Re: Lock in nn_sock_send
- From: Steven Wu <stevenwu.ucd@xxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Mon, 16 Sep 2013 12:34:16 -0400
Hi Martin,
Yes, your scenario will be dead lock. However, if the shared mutex will be
unlocked at first before locking the connection wise lock due to they are
at different stage in the logic, hence a thread should never lock both at
the same time.
Thanks,
Steven
On Mon, Sep 16, 2013 at 10:32 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Hi Steven,
>
>
> Oh, so my understanding is that the nn sockets at a send function have
>> two stages happened which are connections selection by the load balancer
>> or fair-queuer, and the data sending or queued on the selected
>> connections.
>> I think it may be a good idea but of cause it will require more work if
>> we can separate the single shared lock to be a shared lock for the
>> connection selection and locks of connection-wise for the data
>> sending/queued, which can reduce the blocking by overlapping lock on the
>> shared lock when the socket is used by multiple threads.
>>
>
> How would you avoid deadlocks between the two critical sections?
>
> Thread A: User calls API, big lock, small lock, hang
> Thread B: Network event happens, small lock, big lock, hang
>
> Martin
>
>
Other related posts:
