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
