This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #13065] New pthread_barrier algorithm to fulfill barrier destruction requirements.
- From: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- To: Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, David Miller <davem at davemloft dot net>
- Date: Fri, 18 Dec 2015 17:47:18 -0600
- Subject: Re: [PATCH][BZ #13065] New pthread_barrier algorithm to fulfill barrier destruction requirements.
- Authentication-results: sourceware.org; auth=none
- References: <1437342755 dot 19451 dot 55 dot camel at localhost dot localdomain> <1450456968 dot 26597 dot 79 dot camel at localhost dot localdomain>
On 12/18/2015 10:42 AM, Torvald Riegel wrote:
> On Sun, 2015-07-19 at 23:52 +0200, Torvald Riegel wrote:
>> The previous barrier implementation did not fulfill the POSIX
>> requirements for when a barrier can be destroyed. Specifically, it was
>> possible that threads that haven't noticed yet that their round is
>> complete still access the barrier's memory, and that those accesses can
>> happen after the barrier has been legally destroyed.
>> The new algorithm does not have this issue, and it avoids using a lock
> Ping. Attached is a rebased patch.
+ We count the number of threads that have entered (IN). Each thread
+ increments IN when entering, thus getting a position in the sequence of
+ threads that are or have been waiting (starting with 1, so we the position
+ is the number of threads that have entered so far including the current
s/so we the position/the position/ ?
+ adding COUNT to CURRENT_ROUND atomically. Threads that belief that their
+ round is not complete yet wait until CURRENT_ROUND is not smaller than
+ their position anymore.
+ if (i <= cr)
+ goto ready_to_leave;
Is the else here only hit if the number of participating threads is
greater than the barrier count?
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