Takashi Yano wrote:
> As you mentioned in private mail to me, this seems to be a regression of
> pthread::once() introduced by
> commit 2c5433e5da8216aaf7458e50c63683c68fb0d3e8.
>
> I'll submit a patch for that issue shortly.
My workaround implementation of pthread_once (in gnulib) looks like this:
/* This would be the code, for
typedef struct
{
pthread_mutex_t mutex;
_Atomic unsigned int num_threads;
_Atomic unsigned int done;
}
pthread_once_t;
*/
if (once_control->done == 0)
{
once_control->num_threads += 1;
pthread_mutex_lock (&once_control->mutex);
if (once_control->done == 0)
{
(*initfunction) ();
once_control->done = 1;
}
pthread_mutex_unlock (&once_control->mutex);
if ((once_control->num_threads -= 1) == 0)
pthread_mutex_destroy (&once_control->mutex);
}
It makes sure that
- The last thread that had been dealing with the mutex deletes
the mutex.
- Once the mutex is deleted, is it never again accessed. The
entry test of the 'done' boolean ensures this.
Bruno
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
