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
