[PATCH][BZ #13065] New pthread_barrier algorithm to fulfill barrier destruction requirements.

[Paul E. Murphy]

On 12/21/2015 02:34 PM, Torvald Riegel wrote:
> On Fri, 2015-12-18 at 17:47 -0600, Paul E. Murphy wrote:
>>
>> On 12/18/2015 10:42 AM, Torvald Riegel wrote:
>> +	  if (i <= cr)
>> +	    goto ready_to_leave;
>> +	  else
>> +	    break;
>>
>> Is the else here only hit if the number of participating threads is
>> greater than the barrier count?
> 
> Yes.  the surrounding block is only run if we finish previous rounds or
> the current one, and if the CAS used for finishing it succeeds; if we
> finished the current round (i <= cr), we're ready to leave; otherwise,
> we finished a previous round, which in turn means that there must be
> more threads trying to enter the barrier than the barrier count (which
> isn't disallowed by POSIX).
> 
> Would you like to see a clarifying comment regarding this?

In hindsight, I believe the question is answered in the comment ahead of
it. I don't think an extra comment is necessary.

>> Otherwise, it looks good to me, and seems like a good improvement to
>> have. Though, a more experienced reviewer may have more to say. This
>> is a bit more complicated than its predecessor. I'll test it on PPC
>> next week.
> 
> Thanks!

Tested out fine on POWER8/PPC64LE. I was curious what the performance
difference might be, so I slapped together the attached program. It
showed about 25% improvement with 64 thread/64 count/100000 iter input
on a 16 core machine.

-Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: barrier.c
Type: text/x-csrc
Size: 2210 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20151222/c9eb66ea/attachment.bin>