aboutsummaryrefslogtreecommitdiff
path: root/nptl
diff options
context:
space:
mode:
authorCarlos O'Donell <carlos@redhat.com>2017-05-03 15:24:43 -0400
committerCarlos O'Donell <carlos@redhat.com>2017-05-03 15:24:43 -0400
commitfa17b9c72035d29d359c6ff5bb7b877f5689598b (patch)
treeec0cd461ba3715c6836e29bff359af2a0e4dd01a /nptl
parentb62c3815912bc679a966134affdedd3f35ae8621 (diff)
downloadglibc-fa17b9c72035d29d359c6ff5bb7b877f5689598b.tar
glibc-fa17b9c72035d29d359c6ff5bb7b877f5689598b.tar.gz
glibc-fa17b9c72035d29d359c6ff5bb7b877f5689598b.tar.bz2
glibc-fa17b9c72035d29d359c6ff5bb7b877f5689598b.zip
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.
Diffstat (limited to 'nptl')
-rw-r--r--nptl/pthread_create.c13
1 files changed, 11 insertions, 2 deletions
diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
index d0d74149d3..c7d1b8f413 100644
--- a/nptl/pthread_create.c
+++ b/nptl/pthread_create.c
@@ -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