April 30, 2004 linux synchronization and pthreads | ||||
---|---|---|---|---|
| ||||
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 |
May 03, 2004 Re: linux synchronization and pthreads | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | "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? |
Copyright © 1999-2021 by the D Language Foundation