diff options
author | Jeff Darcy <jdarcy@redhat.com> | 2016-03-10 08:56:33 -0500 |
---|---|---|
committer | Vijay Bellur <vbellur@redhat.com> | 2016-03-10 12:39:30 -0800 |
commit | b9dbfcc8f5a34cea02d97c047ebb24e057b146a3 (patch) | |
tree | 38d608dac8af1487fcc798cc3c8edd35bcb110e6 /tests/bugs/snapshot | |
parent | 2bfdc30e0e7fba6f97d8829b2618a1c5907dc404 (diff) |
fdl: fix race during initialization
There was a race between fdl_worker starting to run and setting
this->private in fdl_init. This should never happen on a
multiprocessor, since the new thread should start on a different core
and creating it there should take many times longer than getting from
pthread_create to the end of fdl_init on the original core. The only
way it seems likely is if the new thread is started on the same core
that's already in fdl_init, and the new thread preempts the old, which
many would consider broken . . . but there are plenty of broken thread
implementations and it's hardly surprising that glibc has one. Still,
it's a race and it did show up in regression tests a few times, so it
needs to be fixed.
Change-Id: Ifa5b0ae1ec111860f0d3f55a98aa2b8f2cef84ca
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: http://review.gluster.org/13674
Smoke: Gluster Build System <jenkins@build.gluster.com>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Diffstat (limited to 'tests/bugs/snapshot')
0 files changed, 0 insertions, 0 deletions