[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240723235059.GY10433@brightrain.aerifal.cx>
Date: Tue, 23 Jul 2024 19:51:00 -0400
From: Rich Felker <dalias@...c.org>
To: Li JinCheng <naiveli233@...look.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: 回复: RE: Maybe A Bug
about timer_create and pthread_barrier_wait
On Thu, Jul 11, 2024 at 02:56:55PM +0000, Li JinCheng wrote:
> Hi
> >pthread_barrier_destroy() waits for all threads to be done using the
> >barrier before destroying it. Without it, the storage for the barrier
> >can be deallocated when timer_create() returns while the other thread is
> >still using it inside the pthread_barrier_wait() implementation.
>
> Sorry, I have changed to use outlook to send emails. Back to the
> original topic, I don't think add pthread_barrier_destroy in
> timer_create can solve this bug. In timer_create, b->_b_limit should
> be 1, and it will never meet the waiting condition (b->_b_limit < 0)
> in pthread_barrier_destroy.
> And I think add additional synchronization to timer_create is a
> temporary method. Maybe some bugfix is needed in
> pthread_barrier_wait.
There's an old unverified suspicion that our pthread barrier
implementation has serious flaws. Unfortunately I hadn't gotten around
to looking into it, partly because it's such an obscure sync primitive
that almost nothing uses. We really DO need to fix it, but I don't
want fixing timer_create to be blocked on that. Attached is a patch
I'll probably apply (not yet tested) that just uses semaphores instead
of a barrier. I think this will be an improvement even after barriers
are fixed, since it will avoid pulling in the barrier code in static
linking.
Rich
View attachment "timer_create_avoid_barrier.diff" of type "text/plain" (1433 bytes)
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.
