Emmanuel, 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. FWIW, glusterd_do_replace_brick is injecting an event into the state machine queue and invoking the state machine from a different thread. But this execution interleaved with another thread executing the state machine (glusterd_op_sm()) doesn't seem to cause the misusage you observe. That leads me to wonder why we see the EPERM in pthread_mutex_unlock. ----- Original Message ----- > Hello > > in glusterd_op_sm(), we lock and unlock the gd_op_sm_lock mutex. > Unfortunately, locking and unlocking can happen in different threads > (task swap will occur in handelr call). > > This case is explictely covered by POSIX: the behavior is undefined. > http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html > > When unlocking from a thread that is not owner, Linux seems to be fine > (though you never know with unspecified operation), while NetBSD returns > EPERM, causing a spurious error in tests/basic/pump.t . It can be observed > in a few failed tests here: > http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/ > > Fixing it seems far from being obvious. I guess it needs to use syncop, > but the change would be intrusive. Do we have another option? Is it > possible to switch a task to a given thread? > > -- > Emmanuel Dreyfus > manu@xxxxxxxxxx > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
