This is the mail archive of the libc-alpha@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]

Re: [PATCH] Bug #20116: Clarify barrier-like and mutex-like behaviours of PD->lock.


On 03/14/2017 02:07 AM, Carlos O'Donell wrote:
On 02/14/2017 06:32 AM, Florian Weimer wrote:
On 02/13/2017 07:49 PM, Florian Weimer wrote:
On 02/13/2017 02:29 PM, Carlos O'Donell wrote:
+   It is important to point out that PD->lock is being used as a POSIX
+   barrier and a POSIX mutex.  The lock is taken in the parent to force
+   the child to wait, and then the child releases the lock, in effect a
+   barrier.  However, this barrier-like effect is used only for
+   synchronizing the parent and child.  After startup the lock is used
+   like a mutex to create a critical region during which a single owner
+   modifies the thread parameters.

I had missed that the lock was reused for the scheduler parameter.

But the current code still does not make sense to me.  Why do we need to
keep a copy of the scheduler parameters at all?  Is this just a cache to
improve performance, similar to what we used to do for the PID?

The cache is used in the implementation of PTHREAD_PRIO_PROTECT mutexes.  There are data races:

  https://sourceware.org/bugzilla/show_bug.cgi?id=21160

I expect that the use of ->lock to protect these members will go away eventually.

Yes, it's used in tpp.

Given your current understand is the above additional text sufficient
to clarify the situation?

Yes, I'm mostly fine with it. I wouldn't call it a “POSIX barrier” and “POSIX mutex” though, it clearly is not.

Maybe use “as a barrier (acquired and released by different threads and as a mutex (acquired and released by the same thread, providing mutual exclusion)”.

Thanks,
Florian


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