6 Dec
2005
6 Dec
'05
8:59 p.m.
On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote:
On Wed, 2 Nov 2005 11:05:34 +0100
Stéphane Letz <letz(a)grame.fr> wrote:
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
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.
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). 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