Re: Lock Constrains about Fast Dispatch for Messenger

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Other thread                   Messenger's thread
       lock()                          connection lock()
  send_message()                  connect
 try connection lock()         ms_fast_connect()
                                                try lock()

                          DEAD LOCK

supplement

On Tue, Dec 2, 2014 at 4:27 PM, Haomai Wang <haomaiwang@xxxxxxxxx> wrote:
> Hi Gregoy and Sage,
>
> I'm just writing Messenger's unit tests to ensure that SimpleMessenger
> and AsyncMessenger behavior same and expected.
>
> I think the most unclear thing is the lock rule of fast dispatch. When
> introduced fast dispatch, there exists three methods
> "ms_fast_connect", "ms_fast_accept", "ms_fast_dispatch" will be called
> within Messenger's thread. Because without fast dispatcher all
> messages are delivered from queue to queue, fast path will result in
> potential dead lock I think.
>
> "ms_fast_accept" and "ms_fast_connect" are called with
> "pipe_lock"(Pipe) or "lock"(AsyncConnection). And
> Connection::send_message will called outsider. So it may happen:
>
> Other thread                   Messenger's thread
>        lock()                          connection lock()
>   send_message()                  connect
>  try connection lock()         ms_fast_connect()
>
>                           DEAD LOCK
>
> So I'm not sure whether we have some lock rules whether on caller side
> or ms_fast_connect/accept side. For example, ms_fast_connect/accept
> can't acquire the same lock with send_message?
>
> --
>
> Best Regards,
>
> Wheat



-- 
Best Regards,

Wheat
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux