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

[Carlos O'Donell]

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?

-- 
Cheers,
Carlos.