On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote: > On Wed, 2 Nov 2005 11:05:34 +0100 > Stéphane Letz <[EMAIL PROTECTED]> wrote: > > > In Jackdmp we have tested 2 system for inter-process synchronization: > > fifo (the way it was done in regular jackd) and POSIX named semaphore > > (which are built on top of futex on recent system version) > > > > In both cases, each already running client get access to the > > synchronization primitive (fifo or POSIX named sema) defined by a new > > coming client. The synchronization primitive is "opened" once when a > > new client appears and is "closed" when the client quits. The > > synchronization primitive that has to be signaled then depends of the > > graph topology. > > > > > But ISTR that OSX only has named shared futexes (i.e. accessed > > > via a file descriptor), and then of course the problem remains. > > > > On OSX, on can use Mach semaphore (internal and non portable...) > > POSIX named semaphore or fifo. > > > > Stephane > > What results did you get? Did the semaphore perform better/worse than > the fifo? What about pthread condition variables with pshared flag set? > I read somewhere it should be implemented by now (at least on 2.6 > systems).
I've tested process shared mutexes/CVs with NPTL 2.3.5 on Linux 2.6 and it works perfectly - I'm able to synchronize multiple processes via a mutex/CV residing in shared memory, backed by an mmap'ed file in /tmp. The performance is indistinguishable from the single multithreaded process case. Is there any good reason JACK could not use this rather than FIFOs? Lack of robustness? Lee