Re: pthread_mutex misusage in glusterd_op_sm

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

 



My preference would be synclock_t because it was built
(mainly) for the case where pthread_mutex behaviour is undefined (or incorrect)
when the thread executing the lock and unlock is not guaranteed to
be same (viz. due to synctask).

Thanks for testing the suggestion. Would you be sending a patch
using synclock_t?

~kp

----- Original Message -----
> On Thu, Nov 27, 2014 at 01:42:33AM -0500, Krishnan Parthasarathi wrote:
> > 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?
> 
> That seems to address the problem, but you are certainly much more
> knwoledgable than me on whether it is better or equivalent to using
> a mutex-protected boolean.
> 
> --
> Emmanuel Dreyfus
> manu@xxxxxxxxxx
> 
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux