• Ben Hinkle (13/13) Apr 30 2004 On Linux DMD uses the default pthread_mutexattr which deadlocks if a thr...
• Walter (8/21) May 02 2004 thread

"Ben Hinkle" <bhinkle4 juno.com> writes:

On Linux DMD uses the default pthread_mutexattr which deadlocks if a thread
that owns the lock tries to acquire it again. That means a synchronized
method can't call another synchronized method. The D spec doesn't say this
should be possible but I'd expect synchronized blocks to be reentrant. GDC
does set the default mutexattr to be the reentrant PTHREAD_MUTEX_RECURSIVE.
Can dmd do the same?

The file in question is the linux portion of phobos/internal/monitor.c when
it calls
 pthread_mutex_init(cs, 0);

The GDC readme says the pthread reentrant mutex "can cause starvation
problems on Linux" so there might be issues with using it but it seems like
the current behavior should be changed.

-Ben

"Walter" <newshound digitalmars.com> writes:

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c6u50j$7e1$1 digitaldaemon.com...
 On Linux DMD uses the default pthread_mutexattr which deadlocks if a

thread
 that owns the lock tries to acquire it again. That means a synchronized
 method can't call another synchronized method. The D spec doesn't say this
 should be possible but I'd expect synchronized blocks to be reentrant.

You're right.

 GDC
 does set the default mutexattr to be the reentrant

PTHREAD_MUTEX_RECURSIVE.
 Can dmd do the same?

 The file in question is the linux portion of phobos/internal/monitor.c

when
 it calls
  pthread_mutex_init(cs, 0);

 The GDC readme says the pthread reentrant mutex "can cause starvation
 problems on Linux" so there might be issues with using it but it seems

like
 the current behavior should be changed.

Yes. What exactly is the change, and I'll fold it in?