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