ANSI/IEEE POSIX 1003.1 and GCC (+ Other GNU)

[Andrew Pinski]

Sent from my iPhone

On Jan 7, 2010, at 1:59 AM, Takis Psarogiannakopoulos  
<takis@XFree86.Org> wrote:

>
> Guys,
>
> While looking the GCC code, all the releases really from the 3.X.X
> the GNU gettext/libintl lock.c,h code  the GCC/libjava code, the
> GCC/libgomp code, I have observed that the  thread-id zero is widely
> used to initialize/free recursive mutexes/monitors etc.
>
> Eg GCC 4.X.X, libgomp/config/posix95/lock.c
> It implemnts recursive mutexes with the obvious intuitive idea
>
> typedef struct
> {
>  pthread_mutex_t lock;
>  pthread_t owner;
>  int count;
> } omp_nest_lock_t;
>
> However when this is implemented in config/posix95/lock.c
>
> void
> omp_unset_nest_lock (omp_nest_lock_t *lock)
> {
>  lock->count--;
>
>  if (lock->count == 0)
>    {
>      lock->owner = (pthread_t) 0;
>      pthread_mutex_unlock (&lock->lock);
>    }
> }
>
> It is definitely wrong to make such assumptions about the thread-id  
> zero.
> The behaviour according to the posix standard should be undefined.  
> Easy
> fix on all those would be to choose an impossible thread id aka say  
> -1.
> The right thing to do is use the depth (count above) of the mutex to
> decide if the mutex is free. The owner shoud be valid only if the  
> mutex is
> locked.
> The posix stanard IEEE POSIX 1003.1 doesnt have any special
> provisions for the thread id zero, in fact it can be a newly created
> thread inside the process and can happen that this thread is NOT
> necessarily the main one. In which case we have an obvious deadlock.
>
> Similar scenarios we find in posix-thread.cc GCC/libjava
>
>  // Release the monitor mutex.
>  mu->count = 0;
>  mu->owner = 0;
>  pthread_mutex_unlock (&mu->mutex);
>
>
> _Jv_MutexInit (_Jv_Mutex_t *mu)
> {
> # ifdef LOCK_DEBUG /* Assumes Linuxthreads */
>  pthread_mutexattr_t attr;
>  pthread_mutexattr_init(&attr);
>  pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
>  pthread_mutex_init (&mu->mutex, &attr);
> # else
>  pthread_mutex_init (&mu->mutex, 0);
> # endif
>
>  mu->count = 0;
>  mu->owner = 0;
> }
>
> in which case, if there was meanwhile a thread-id zero thread we just
> going for  a deadlock because the monitor is anything else than free!
>
> As there is an strong effort over the years in the GNU community to
> conform with standards I would hope somene would correct these.
>

As long as owner is not used when count is 0, then I don't see an  
issue. Note I know libobjc does implement it incorrectly; I have not  
had time to fix that.
Thanks,
Andrew Pinski



> Kind Regards,
>
>