Thanks Emmanuel. Around about the same time we managed to find the sequence of function calls that could lead to this. Since the rpc program handling LOCK/STAGE/COMMIT/UNLOCK requests from other peers invokes the corresponding handler function in a synctask, I am inclined to use synclock_t in place of pthread_mutex for gd_op_sm_lock. synclock_t identifies the locker based on the task and not the thread executing the 'lock/unlock' function. Thoughts? ----- Original Message ----- > Krishnan Parthasarathi <kparthas@xxxxxxxxxx> wrote: > > > Could you explain which sequence of function calls lead to > > mutex lock and mutex unlock being called by different threads? > > Meanwhile, I am trying to find one such sequence to understand > > the problem better. > > In the middle of the function is the handler call: > handler = state[event_type].handler; > GF_ASSERT (handler); > > ret = handler (event, event->ctx); > > Between the call and the return, the current task may have moved to a > different thread. I guess handler must send a network request, and the > ability to return in a different thread is normal synctask at work. > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > manu@xxxxxxxxxx > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
