This is the mail archive of the glibc-cvs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GNU C Library master sources branch master updated. glibc-2.25-268-gfa17b9c


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  fa17b9c72035d29d359c6ff5bb7b877f5689598b (commit)
      from  b62c3815912bc679a966134affdedd3f35ae8621 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=fa17b9c72035d29d359c6ff5bb7b877f5689598b

commit fa17b9c72035d29d359c6ff5bb7b877f5689598b
Author: Carlos O'Donell <carlos@redhat.com>
Date:   Wed May 3 15:24:43 2017 -0400

    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.

diff --git a/ChangeLog b/ChangeLog
index fa61e5f..c2d13f1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -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.
diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
index d0d7414..c7d1b8f 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

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog             |    8 +++++++-
 nptl/pthread_create.c |   13 +++++++++++--
 2 files changed, 18 insertions(+), 3 deletions(-)


hooks/post-receive
-- 
GNU C Library master sources


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]