redesign and simplify vmlock system
authorRich Felker <dalias@aerifal.cx>
Fri, 10 Apr 2015 06:27:52 +0000 (02:27 -0400)
committerRich Felker <dalias@aerifal.cx>
Fri, 10 Apr 2015 06:27:52 +0000 (02:27 -0400)
commitf08ab9e61a147630497198fe3239149275c0a3f4
tree65f0898637a5306485e665ec95c753b99f4e3740
parent4e98cce1c529a304d7b55b5455078b9532f93e9b
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.
src/internal/pthread_impl.h
src/mman/mmap.c
src/mman/munmap.c
src/thread/pthread_barrier_destroy.c
src/thread/pthread_barrier_wait.c
src/thread/pthread_create.c
src/thread/pthread_mutex_unlock.c
src/thread/vmlock.c