summaryrefslogtreecommitdiff
path: root/src/thread/pthread_attr_setschedpolicy.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2015-04-10 02:27:52 -0400
committerRich Felker <dalias@aerifal.cx>2015-04-10 02:27:52 -0400
commitf08ab9e61a147630497198fe3239149275c0a3f4 (patch)
tree65f0898637a5306485e665ec95c753b99f4e3740 /src/thread/pthread_attr_setschedpolicy.c
parent4e98cce1c529a304d7b55b5455078b9532f93e9b (diff)
downloadmusl-f08ab9e61a147630497198fe3239149275c0a3f4.tar.gz
redesign and simplify vmlock system
this global lock allows certain unlock-type primitives to exclude mmap/munmap operations which could change the identity of virtual addresses while references to them still exist. the original design mistakenly assumed mmap/munmap would conversely need to exclude the same operations which exclude mmap/munmap, so the vmlock was implemented as a sort of 'symmetric recursive rwlock'. this turned out to be unnecessary. commit 25d12fc0fc51f1fae0f85b4649a6463eb805aa8f already shortened the interval during which mmap/munmap held their side of the lock, but left the inappropriate lock design and some inefficiency. the new design uses a separate function, __vm_wait, which does not hold any lock itself and only waits for lock users which were already present when it was called to release the lock. this is sufficient because of the way operations that need to be excluded are sequenced: the "unlock-type" operations using the vmlock need only block mmap/munmap operations that are precipitated by (and thus sequenced after) the atomic-unlock they perform while holding the vmlock. this allows for a spectacular lack of synchronization in the __vm_wait function itself.
Diffstat (limited to 'src/thread/pthread_attr_setschedpolicy.c')
0 files changed, 0 insertions, 0 deletions