On Tue, Dec 2, 2014 at 12:26 AM, 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 Sorry, which lock() is the "Other thread" calling? It's not like anybody can access the Pipe's lock before it has been connect()ed. Or perhaps you're referring to some kind of global lock that you're worried ms_fast_connect() will try and access? In that case, yes, the rules on locking within the Dispatcher *fast* functions are very strict. We basically don't want any of them to take locks at all; in the case of the OSD we don't quite manage that and have had to dance through a number of hoops to avoid various tight races, but we're very close. -Greg -- 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
