[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240724002538.GC10433@brightrain.aerifal.cx>
Date: Tue, 23 Jul 2024 20:25:38 -0400
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: musl@...ts.openwall.com
Subject: Re: Re: Maybe A Bug about timer_create and
pthread_barrier_wait
On Wed, Jul 24, 2024 at 12:11:28AM +0000, Thorsten Glaser wrote:
> Rich Felker dixit:
>
> >There's an old unverified suspicion that our pthread barrier
> >implementation has serious flaws. Unfortunately I hadn't gotten around
>
> From having looked at the documentation and the OP’s description
> of their understanding of the issue (I don’t understand enough of
> the actual code), I got the idea that maybe the musl implementation
> accesses the pthread_barrier_t object after at least one of the
> threads has returned (which can lead to freeing the object by the
> caller). I don’t know enough about parallel programming to be any
> more help in debugging that though, or even in checking whether
> that’s indeed the case.
The contract of pthread barriers is that the barrier object is no
longer in use (and thus fair game to free/clobber) as soon as any
waiter has returned. This is an extremely strong constraint on the
implementation making for an extremely easy-to-use primitive for the
application, assuming it actually works.
I wrote this code a long, long time ago, but with the intent that it
works, based on doing the actual synchronization in the non-pshared
case with objects on the waiters' stacks rather than the barrier
object, and just using the barrier object to mediate setup of a wait
instance. But there's probably something wrong. I just have to go back
and understand it well enough to figure out what...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
