summaryrefslogtreecommitdiffstats
path: root/tests/volume.rc
diff options
context:
space:
mode:
authorKrishnan Parthasarathi <kparthas@redhat.com>2014-11-28 17:24:13 +0530
committerKaushal M <kaushal@redhat.com>2014-12-01 21:47:13 -0800
commitf5ef4d808724afe4ddd477b0c0e8b3eb985319db (patch)
treedcc3903bb728290ea7e60ef20c3ace2c0f1d1bda /tests/volume.rc
parent24581a58e897a415dfcc96f65c41d82d0f1fb49a (diff)
glusterd: use synclock_t for synchronizing concurrent '\op_sm\' invocations
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 handler call with use of synctasks). 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. To fix this, we use synclock_t which was precisely meant for this. synclock is a pthread_mutex_t like synchronization object which uses the synctask handle for owner and is immune to the task being run on multiple threads during its lifetime. Change-Id: Idca15190d42f32a843088cc8236138f676377586 BUG: 1129939 Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com> Reviewed-on: http://review.gluster.org/9212 Reviewed-by: Kaushal M <kaushal@redhat.com> Tested-by: Kaushal M <kaushal@redhat.com>
Diffstat (limited to 'tests/volume.rc')
0 files changed, 0 insertions, 0 deletions