[Gluster-devel] pthread_mutex misusage in glusterd_op_sm

[Krishnan Parthasarathi]

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 at redhat.com> 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 at netbsd.org
>