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.
Kind Regards,
