pthread and mutex problems in gcc-3.0

[Stephen Brandon]

Hi,

gcc-3.0, linux/x86 (Caldera OpenLinux), pthreads

I am working on the SndKit and MusicKit ports for GNUstep, and have found 
some issues in gcc-3.0 with respect to mutex "trylock"ing.

I am looking for clarification about whether this is a known bug, and if 
there are any technical reasons why it should not have a simple patch.

DESCRIPTION:

The function in question is objc_mutex_trylock.

This calls __objc_mutex_trylock(), and returns its status if != 0

If the status is ok, objc_mutex_trylock returns the new mutex depth, locking 
setting the new owner as the current thread if it needs to.

The API for objc_mutex_trylock is (as I understand it) that it returns -1 for 
failure, or positive integers for success (the new depth of the lock).

NOW, the problem is this:

objc_mutex_trylock() (in libobjc/thr.c) calls __objc_mutex_trylock() 
(libobjc/thr-objc).

_objc_mutex_trylock() (libobjc/thr-objc) calls __gthread_objc_mutex_trylock() 
(gcc/gthr-posix.h)

The function thus called is:
/**************************************************************************/
/* Try to grab a lock on a mutex. */
static inline int
__gthread_objc_mutex_trylock(objc_mutex_t mutex)
{
  if (__gthread_active_p ())
    return pthread_mutex_trylock((pthread_mutex_t *)mutex->backend);
  else
    return 0;
}
/**************************************************************************/

... and pthread_mutex_trylock() returns error codes such as EBUSY (int 16), 
which then gets passed up the chain and eventually returned as the depth of 
the lock, rather than -1, the expected error code.

Further up the chain this causes an exception to be thrown by 
NSConditionLock:-tryLockWhenCondition when it tries to lock on a lock held by 
another thread AND the condition is wrong. This is because the initial 
-tryLock succeeds when it should not (return value EBUSY = 16), then the 
-unlock fails, because it realises it is not the owner. So it throws.

What I would expect the function to look like is something like the file 
libobjc/thr-posix.c (seems to be unused in the gcc-3.0 distribution) which 
has the following function:

/**************************************************************************/
/* Try to grab a lock on a mutex. */
int
__objc_mutex_trylock(objc_mutex_t mutex)
{
  if (pthread_mutex_trylock((pthread_mutex_t *)mutex->backend) == 0)
    return 0;
  else
    return -1;
}
/**************************************************************************/

QUESTIONS:

(1) Is it possible to configure gcc-3.0 to use the libobjc/thr-posix.c 
backend instead of the libobjc/thr-objc and gcc/gthr-posix.h pair? I have 
tried to configure with --enable-threads=pthreads, but this no longer selects 
the backend from libobjc/thr-*.c, but points to gcc/gthr-*.h, and there isn't 
a gthr-pthreads there...

(2) Is there any good reason why gcc/gthr-posix.h uses the wrong behavior? eg 
are there non-objc libraries which rely on the behaviour of returning error 
codes such as EBUSY from attempts to trylock?

(3) If I created a gcc/gthr-pthreads.h with the fix I am looking for, then 
configured with --enable-threads=pthreads, would this break anything relying 
on the old behaviour (ie would gcc still have the other file compiled in, but 
libobjc have the version I had created)?

(4) Is there some way to compile libobjc separately from the rest of the 
gcc-3.0 install, and thus use the old way of specifying the back end? 
(libobjc/thr-*.c) This would be good since there's a bug-free version in 
there; thr-pthreads.c

I would be very happy to create a patch and put it on a web site somewhere, 
but I just want to make sure that it won't break expected behaviour for 
anyone else.

Cheers,
Stephen Brandon
stephen@brandonitconsulting.co.uk