OpenE2K
/
glibc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Bug 20116: Clarify behaviour of PD->lock. 

Add comments to the concurrency notes to clarify the semaphore-like and
mutex-like behaviours of PD->lock.
This commit is contained in:
Carlos O'Donell 2017-05-03 15:24:43 -04:00
parent b62c381591
commit fa17b9c720
2 changed files with 18 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
ChangeLog
View File

@ -1,4 +1,10 @@
2016-04-03 Adhemerval Zanella <adhemerval.zanella@linaro.org>
2017-05-03 Carlos O'Donell <carlos@redhat.com>
[BZ #20116]
* nptl/pthread_create.c: Expand comments to describe
semaphore-like and mutex-like uses of PD->lock.
2017-04-03 Adhemerval Zanella <adhemerval.zanella@linaro.org>
* sysdeps/unix/sysv/linux/epoll_wait.c: New file.
* sysdeps/unix/sysv/linux/generic/epoll_wait.c: Remove file.

13
nptl/pthread_create.c
View File

@ -94,8 +94,17 @@ unsigned int __nptl_nthreads = 1;
exactly which of the four ownership states we are in and therefore
what actions can be taken. For example after (2) we cannot read or
write from PD anymore since the thread may no longer exist and the
memory may be unmapped. The most complicated cases happen during
thread startup:
memory may be unmapped.
It is important to point out that PD->lock is being used both
similar to a one-shot semaphore and subsequently as a mutex. The
lock is taken in the parent to force the child to wait, and then the
child releases the lock. However, this semaphore-like effect is used
only for synchronizing the parent and child. After startup the lock
is used like a mutex to create a critical section during which a
single owner modifies the thread parameters.
The most complicated cases happen during thread startup:
(a) If the created thread is in a detached (PTHREAD_CREATE_DETACHED),
or joinable (default PTHREAD_CREATE_JOINABLE) state and