Thanks! On Tue, Dec 2, 2014 at 11:03 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: > 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 -- 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
