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

"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?