29 Oct
2005
29 Oct
'05
8:42 p.m.
Hi,
I have two questions concerning the jack callback,
1. what is the preferred way of feeding data from disk to the callback?
Is there a general design pattern agreed upon? Best Practices?
2. What is the preferred way to notify the non-realtime thread that
something happened in the jack-callback?
A condition variable? How to avoid blocking? How do you do it?
I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses
mutex+condition, is it okay to do this? Are there better ways?
thx
-Richard
29 Oct
29 Oct
10:01 p.m.
On Sun, 2005-10-30 at 00:42 +0200, Richard Spindler wrote:
I have two questions concerning the jack callback,
1. what is the preferred way of feeding data from disk to the callback?
Is there a general design pattern agreed upon? Best Practices?
The most common way is to use some variant of a non-blocking ringbuffer.
The JACK library has a ringbuffer that you can use for this, see
http://jackit.sourceforge.net/docs/reference/html/ringbuffer_8h.html
2. What is the preferred way to notify the
non-realtime thread that
something happened in the jack-callback?
It depends on how detailed information you want in the non-RT thread. If
you just want to say "something happened!" you can use a counter of a
datatype that you know is read and written atomically (int usually
works) and increase it every time something happens. The non-RT thread
can then compare the counter's value to the value it had last time it
looked at it, and if it's different it knows that something has
happened. If you need to more detailed information you can define a
message struct or enum and use a ringbuffer of the same type as above to
send those messages to the non-RT thread.
I read the tutorial at
http://userpages.umbc.edu/~berman3/ , it uses
mutex+condition, is it okay to do this? Are there better ways?
Locking a mutex in the process callback is usually not considered OK for
a JACK program that is meant to run in realtime, because it can yield
the CPU to some other process or thread while waiting for the mutex,
which can cause unneccessary xruns.
--
Lars Luthman
PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
30 Oct
30 Oct
3:28 a.m.
2005/10/30, Lars Luthman <larsl(a)users.sourceforge.net>et>:
It depends on how detailed information you want in the
non-RT thread. If
you just want to say "something happened!" you can use a counter of a
datatype that you know is read and written atomically (int usually
works) and increase it every time something happens. The non-RT thread
can then compare the counter's value to the value it had last time it
looked at it, and if it's different it knows that something has
happened.
This would imply busy waiting, right?
related question, what happens if I use the lockfree ringbuffer, and
the non-realtime-thread tries to access it while it's full, how do I
know when to try again?
BTW. @all: thx for all the detailed answers.
-Richard
3:47 a.m.
2005/10/30, Richard Spindler <richard.spindler(a)gmail.com>om>:
related question, what happens if I use the lockfree
ringbuffer, and
the non-realtime-thread tries to access it while it's full, how do I
know when to try again?
Replying to myself:
I just read the capture_client.c, it uses pthread_mutex_trylock and
pthread_cond_signal, so I guess, that is okay. :)
-Richard
29 Oct
29 Oct
10:12 p.m.
On Sun, Oct 30, 2005 at 12:42:47AM +0200, Richard Spindler wrote:
1. what is the preferred way of feeding data from disk
to the callback?
Use a separate thread to read ahead. Trigger it in the same way as
you would for a thread that takes data from the callback.
2. What is the preferred way to notify the
non-realtime thread that
something happened in the jack-callback?
A condition variable? How to avoid blocking? How do you do it?
In all my apps I use threads from (my own) libclthreads which is a
thin C++ abstaction of POSIX threads plus a communication system.
All these threads contain an object that encapsulates a set of 16
message queues implemented as linked lists, and 16 counting
semaphores, all 32 of them using a single condition variable plus
mutex. A thread can wait on any subset of these events and optionally
on a timeout.
To tell another thread that a callback has occured, I signal
(increment) one of the semas in the destination thread. There is
a very tiny chance that this could block, if the destination
happened to be in the (very short) critical section reading its
input events when it was pre-empted by jack's callback thread
(I've never seen this happen).
If this is not acceptable, there is also a non-blocking version
of the sema operation. It fails when the normal one would block.
In that case the callback just remembers this and increments by
one more next time.
In more complex situations I would use a message containing
parameters for the other thread instead of the sema. Since
the message mechanism is zero-copy, there's virtually no
overhead compared to the sema, and it's anyway deliverd by
the same trigger.
On a 2.6 system you could also use futex based semaphores.
AFAIK, they never block on the V operation.
--
FA
30 Oct
30 Oct
1:05 a.m.
On Sun, 2005-30-10 at 00:42 +0200, Richard Spindler wrote:
I read the tutorial at
http://userpages.umbc.edu/~berman3/ , it uses
mutex+condition, is it okay to do this? Are there better ways?
That's a wonderful tutorial... on how NOT to write a Jack client.
(There's no lock free data structures "in C" or Linux? There's one
_included with Jack_...)
On mutexes, calling pthread_mutex_trylock in the process thread is okay,
but pthread_mutex_lock is not. Don't Do That(TM).
-DR-
7:11 a.m.
On Sun, 30 Oct 2005 14:03:39 +1100
Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
On Sun, 2005-30-10 at 00:42 +0200, Richard Spindler
wrote:
The tutorial client can be fixed pretty easily with this (see below),
though as the comment said, the code was written when there didn't exist
a lockfree ringbuffer implementation. This has changed (jack provides
one). I know that you know this David, just restating the obvious for
less experienced readers. Of course the tutorial client still needs to
be considered broken even with the trylock.
Also the basic problem of signalling (in this case the disk thread that
there is work to do) still persists even with lockless ringbuffers. The
other thinkable approach would be to make the diskthread wakeup
regularly and check whether data is available in the ringbuffer. This is
nasty, too, and unsuitable for some situations.
So there's basically these approaches nowadays
- using named pipes and having the signaller passing single bytes
through it to wake up the signallee that blocks on the pipe. This is
really not correct, though it might work ok in practice (see jack/ardour
(in jack it is used to work around the fact that there's no
inter-process mechanism for this though futexes could be used, too, if i
understand correctly)).
- using condition variables
Btw: i think when using a single mutex only for the condition variable
(as opposed to the tutorial client which uses the same mutex for the
signalling _and_ for synchronizing access to its data structure), the
likeliness of contention is rather unprobable given that that the
signaller aquires (again, of course via trylock) right before and
releases the lock right after the pthread_cond_signal/broadcast.
Same for the singallee. As pthread_cond_wait releases the mutex while
waiting and reaquires it before handing back control to the signallee
the contention case becomes very unprobable when aquiring and releasing
the lock right before and after the pthread_cond_wait.
Of course with this strategy the case that trylock fails on the
condition mutex needs to be handled gracefully (i.e. remembering for the
next process callback to try again).
Besides the one mutex used only for the condition var, there maybe need
to be additional mutexes in this scenario for the shared data
structures. Of course from the process callback pthread_mutex_lock is
still a nono (again use trylock and handle failure gracefully). But i
suppose most locking for the shared data can be worked around with
lockless data structures...
Btw: in the general case the signallee should always check for spurious
wakeups which is not nessecary with the capture_client from the jack
distribution as it doesn't hurt to wake up once or twice too often once
in a while (at least not when using a ringbuffer - when it's empty the
signallee simply goes back to waiting). Maybe the pthread_mutex_lock
calls might be moved around the pthread_cond_wait call. The disk thread
has the mutex locked all the time during writing.
int
process (jack_nframes_t nframes, void *arg)
{
thread_info_t *info = (thread_info_t *) arg;
jack_default_audio_sample_t *in;
sample_buffer_t *buf;
unsigned int i;
if (!info->can_process) {
return 0;
}
/* we don't like taking locks, but until we have a lock
free ringbuffer written in C, this is what has to be done
*/
if (pthread_mutex_trylock (&buffer_lock) != 0) {
/* this is the unprobable contention case.
we will simply do nothing here. audio
will be lost. better than an xrun though */
return 0;
}
/* ok, aquired the mutex, so we can do our thing */
buf = get_free_buffer (nframes, nports);
for (i = 0; i < nports; i++) {
in = (jack_default_audio_sample_t *) jack_port_get_buffer (ports[i],
nframes);
memcpy (buf->data[i], in, sizeof (jack_default_audio_sample_t) *
nframes);
}
put_write_buffer (buf);
/* tell the disk thread that there is work to do */
pthread_cond_signal (&data_ready);
pthread_mutex_unlock (&buffer_lock);
return 0;
}
Have fun and correct me where wrong,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
I read the tutorial at
http://userpages.umbc.edu/~berman3/ , it uses
mutex+condition, is it okay to do this? Are there better ways?
That's a wonderful tutorial... on how NOT to write a Jack client.
(There's no lock free data structures "in C" or Linux? There's one
_included with Jack_...)
On mutexes, calling pthread_mutex_trylock in the process thread is okay,
but pthread_mutex_lock is not. Don't Do That(TM).
8:31 a.m.
On Sun, Oct 30, 2005 at 12:11:18PM +0100, Florian Schmidt wrote:
Btw: i think when using a single mutex only for the
condition variable
(as opposed to the tutorial client which uses the same mutex for the
signalling _and_ for synchronizing access to its data structure), the
likeliness of contention is rather unprobable given that that the
signaller aquires (again, of course via trylock) right before and
releases the lock right after the pthread_cond_signal/broadcast.
Same for the singallee. As pthread_cond_wait releases the mutex while
waiting and reaquires it before handing back control to the signallee
the contention case becomes very unprobable when aquiring and releasing
the lock right before and after the pthread_cond_wait.
This can still be so if the access to the shared data structure is
regulated by the same mutex that protects the condition variable,
provided that the operation on the shared data is very simple and fast.
It should never be necessary to hold the mutex while accessing the
samples, only while sending or receiving the information that the
samples are available.
In libclthreads, the operation performed while the mutex is held is
either incr/decr of a counter, or adding/removing an element at
the end/start of a linked list. Both operations are so trivial
that it would be silly to use a separate mutex for them.
The nice thing about condition variables is that they allow you
to re-use the mutex in this way, and in fact that's why they
exist at all.
Thinking a bit further, the conclusion is that the use of lock-free
data structures is warranted only iff the event passing mechanism
is lock-free as well, otherwise nothing is gained.
False wakeups are easy to avoid as well in this way. In libclthreads
the sender will only signal the single CV iff the change of state of
the ITC object (all the semas and mailboxes) would trigger some
action in the receiver, i.e. it checks what the receiver is waiting
for. In the other case only the state is updated.
--
FA
8:53 a.m.
On Sun, 30 Oct 2005 13:36:41 +0100
fons adriaensen <fons.adriaensen(a)skynet.be> wrote:
This can still be so if the access to the shared data
structure is
regulated by the same mutex that protects the condition variable,
provided that the operation on the shared data is very simple and fast.
True..
In libclthreads, the operation performed while the
mutex is held is
either incr/decr of a counter, or adding/removing an element at
the end/start of a linked list. Both operations are so trivial
that it would be silly to use a separate mutex for them.
The nice thing about condition variables is that they allow you
to re-use the mutex in this way, and in fact that's why they
exist at all.
Yeah, but i figured with RT constrains on the signaller it looked a bit
different. Thinking about it a bit more it seems i was wrong :) As in
the other case (a data structure where operations carried out by the
signallee might take a long time (signaller op naturally needs to be
short time RT safe)) there's also nothing gained by seperating the two
mutexes.
Thinking a bit further, the conclusion is that the use
of lock-free
data structures is warranted only iff the event passing mechanism
is lock-free as well, otherwise nothing is gained.
Naturally.
False wakeups are easy to avoid as well in this way.
In libclthreads
the sender will only signal the single CV iff the change of state of
the ITC object (all the semas and mailboxes) would trigger some
action in the receiver, i.e. it checks what the receiver is waiting
for. In the other case only the state is updated.
Oh i thought i read somewhere that when pthread_cond_wait it is not
guaranteed that anyone actually signalled. Will do some more reading.
Thanks for your insights,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
9:09 a.m.
On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote:
Oh i thought i read somewhere that when
pthread_cond_wait it is not
guaranteed that anyone actually signalled. Will do some more reading.
It can return on unix signals, so you have to test for EINTR.
I don't think it will wake up unexpectedly otherwise.
I'm thinking of rewriting the whole ITC object so it uses a
futex instead of the CV (that would also enable it to work
in shared memory across process boundaries), but then I really
need a lock free implementation for the linked lists.
I guess the required primitives are platform dependant.
Is their some library that provides them ?
--
FA
8:44 p.m.
On Sun, 30 Oct 2005 14:14:19 +0100
fons adriaensen <fons.adriaensen(a)skynet.be> wrote:
On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian
Schmidt wrote:
Btw: i just discovered that pthread mutexes and condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be useful for jack, no?
pthread_condvar_setpshared()
pthread_mutexattr_setpshared()
Or do i misread that manpage?
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Oh i thought i read somewhere that when
pthread_cond_wait it is not
guaranteed that anyone actually signalled. Will do some more reading.
It can return on unix signals, so you have to test for EINTR.
I don't think it will wake up unexpectedly otherwise.
I'm thinking of rewriting the whole ITC object so it uses a
futex instead of the CV (that would also enable it to work
in shared memory across process boundaries), but then I really
need a lock free implementation for the linked lists.
I guess the required primitives are platform dependant.
Is their some library that provides them ?
9:13 p.m.
On Mon, Oct 31, 2005 at 01:44:45AM +0100, Florian Schmidt wrote:
Btw: i just discovered that pthread mutexes and
condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be useful for jack, no?
pthread_condvar_setpshared()
pthread_mutexattr_setpshared()
Or do i misread that manpage?
Manpages sometimes document things that are not (yet) implemented.
Maybe it is now (in 2.6) but I'm quite sure it was not in 2.4.
For jack, all you need is the futexes (which are system wide,
I tested that). I'm pretty sure that all of jack can be written
without requiring a mutex shared with the client threads.
A big advantage of using futexes in shared memory would be
that they don't have to be recreated each time the callback
order changes - unlike the pipes, they are not bound to a
process, and to modify the 'trigger chain' all you need is
to change some pointers.
But ISTR that OSX only has named shared futexes (i.e. accessed
via a file descriptor), and then of course the problem remains.
--
FA
2 Nov
2 Nov
6:06 a.m.
Le 31 oct. 05 à 02:18, fons adriaensen a écrit :
On Mon, Oct 31, 2005 at 01:44:45AM +0100, Florian
Schmidt 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.
Btw: i just discovered that pthread mutexes and
condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be useful for jack, no?
pthread_condvar_setpshared()
pthread_mutexattr_setpshared()
Or do i misread that manpage?
Manpages sometimes document things that are not (yet) implemented.
Maybe it is now (in 2.6) but I'm quite sure it was not in 2.4.
For jack, all you need is the futexes (which are system wide,
I tested that). I'm pretty sure that all of jack can be written
without requiring a mutex shared with the client threads.
A big advantage of using futexes in shared memory would be
that they don't have to be recreated each time the callback
order changes - unlike the pipes, they are not bound to a
process, and to modify the 'trigger chain' all you need is
to change some pointers.
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
6:32 a.m.
On Wed, Nov 02, 2005 at 11:05:34AM +0100, St?phane Letz wrote:
Le 31 oct. 05 � 02:18, fons adriaensen a �crit :
I must be missing something essential here. Access to named things
that have to be opened is normally by a file descriptor, and file
descriptors are bound a process. How then can you give *all* clients
access to the named pipe or sema created for a new client ?
--
FA
A big advantage of using futexes in shared memory
would be
that they don't have to be recreated each time the callback
order changes - unlike the pipes, they are not bound to a
process, and to modify the 'trigger chain' all you need is
to change some pointers.
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.
6:57 a.m.
Le 2 nov. 05 à 11:29, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 11:05:34AM +0100, St?phane
Letz wrote:
The synchronization primitive is actually created by the server when
a new client register. Then a client identifier (built using the
actual client name) is transfered to all running clients that will
define/access the synchronization primitive in their own process.
Stephane
Le 31 oct. 05 à 02:18, fons adriaensen a écrit :
I must be missing something essential here. Access to named things
that have to be opened is normally by a file descriptor, and file
descriptors are bound a process. How then can you give *all* clients
access to the named pipe or sema created for a new client ?
- A big advantage of using futexes in shared memory
would be
that they don't have to be recreated each time the callback
order changes - unlike the pipes, they are not bound to a
process, and to modify the 'trigger chain' all you need is
to change some pointers.
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.
7:11 a.m.
On Wed, Nov 02, 2005 at 11:56:59AM +0100, St?phane Letz wrote:
But in order to define/access it in their own process, they have to open()
it, i.e. perfrom a call to the filesystem, or am I wrong here ?
This means that changing the graph order can never be a RT operation,
unless clients get a second, non-RT thread to perform this call from.
(or do it in their own non-RT user code, but that would be horrible).
--
FA
I must be
missing something essential here. Access to named things
that have to be opened is normally by a file descriptor, and file
descriptors are bound a process. How then can you give *all* clients
access to the named pipe or sema created for a new client ?
The synchronization primitive is actually created by the server when
a new client register. Then a client identifier (built using the
actual client name) is transfered to all running clients that will
define/access the synchronization primitive in their own process.
7:39 a.m.
Le 2 nov. 05 à 12:11, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 11:56:59AM +0100, St?phane
Letz wrote:
But in order to define/access it in their own process, they have to
open()
it, i.e. perfrom a call to the filesystem, or am I wrong here ?
Yes, clients use open *once* when the new client opens. This is done
in a non RT thread (what we call the "notification" thread that also
handle all non RT events like callback...)
I must be
missing something essential here. Access to named things
that have to be opened is normally by a file descriptor, and file
descriptors are bound a process. How then can you give *all* clients
access to the named pipe or sema created for a new client ?
The synchronization primitive is actually created by the server when
a new client register. Then a client identifier (built using the
actual client name) is transfered to all running clients that will
define/access the synchronization primitive in their own process. This means that changing the graph order can never be
a RT operation,
unless clients get a second, non-RT thread to perform this call from.
There is no need to open the synchronization primitive at graph re-
order time. Since a given client can access all synchronization
primitive, when the graph order changes, then the client will
possibly have to notify another primitive.
Stephane
8:43 a.m.
On Wed, Nov 02, 2005 at 12:38:49PM +0100, St?phane Letz wrote:
Yes, clients use open *once* when the new client
opens. This is done
in a non RT thread (what we call the "notification" thread that also
handle all non RT events like callback...)
So if there are N clients, each of them needs N file descriptors open
all the time. System wide the complexity grows as N^2. Not really a
good way to tackle an O(N) problem IMHO.
--
FA
This means that changing the graph order can never
be a RT operation,
unless clients get a second, non-RT thread to perform this call from.
There is no need to open the synchronization primitive at graph re-
order time. Since a given client can access all synchronization
primitive, when the graph order changes, then the client will
possibly have to notify another primitive.
8:58 a.m.
Le 2 nov. 05 à 13:43, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 12:38:49PM +0100, St?phane
Letz wrote:
Yes but in the jackdmp data flow kind of model, the actual activation
order is only known when the graph executes.
Or do you have a better idea to do that?
Stephane
Yes, clients use open *once* when the new client
opens. This is done
in a non RT thread (what we call the "notification" thread that also
handle all non RT events like callback...)
So if there are N clients, each of them needs N file descriptors open
all the time. System wide the complexity grows as N^2. Not really a
good way to tackle an O(N) problem IMHO. This means that changing the graph order can
never be a RT
operation,
unless clients get a second, non-RT thread to perform this call
from.
There is no need to open the synchronization primitive at graph re-
order time. Since a given client can access all synchronization
primitive, when the graph order changes, then the client will
possibly have to notify another primitive.
9:05 a.m.
On Wed, Nov 02, 2005 at 01:57:47PM +0100, St?phane Letz wrote:
Yes, don't use named semas, but 'anonymous' ones placed in memory
shared by all clients. Each new client gets two pointers, one to the
sema it has to wait on (fixed for the client's lifetime), and one it
has to signal (changes when the graph is reordered).
But of course if OSX doesn't have them, then it's impossible...
--
FA
So if there are
N clients, each of them needs N file descriptors open
all the time. System wide the complexity grows as N^2. Not really a
good way to tackle an O(N) problem IMHO.
Yes but in the jackdmp data flow kind of model, the actual activation
order is only known when the graph executes.
Or do you have a better idea to do that?
9:23 a.m.
Le 2 nov. 05 à 14:05, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 01:57:47PM +0100, St?phane
Letz wrote:
Yes, don't use named semas, but 'anonymous' ones placed in memory
shared by all clients. Each new client gets two pointers, one to the
sema it has to wait on (fixed for the client's lifetime), and one it
has to signal (changes when the graph is reordered).
But in a data flow model, a given client may have to signal several
semaphores. And the client that actually signals the semaphore is
only known at activation time. For the following graph for example :
--> A
IN --> C
--> B
where A and B can run in parallel, C is activated by the *last*
client of A and B that finish its processing. Thus A and B have to
"know" the C semaphore.
More generally a given client would have to keep a set of semaphores
it may have to signal for a given graph topology. This could improve
the N*N issue but is more difficult to handle.
So if
there are N clients, each of them needs N file descriptors
open
all the time. System wide the complexity grows as N^2. Not really a
good way to tackle an O(N) problem IMHO.
Yes but in the jackdmp data flow kind of model, the actual activation
order is only known when the graph executes.
Or do you have a better idea to do that?
But of course if OSX doesn't have them, then it's impossible...
And OSX does not support them, so i guess we will keep the current
(simple...) implementation in jackdmp until the problem you describe
becomes a real one in real situations...
Stephane
6:49 a.m.
On Wed, 2 Nov 2005 11:05:34 +0100
Stéphane Letz <letz(a)grame.fr> 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.
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).
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
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
7:27 a.m.
Le 2 nov. 05 à 11:48, Florian Schmidt a écrit :
On Wed, 2 Nov 2005 11:05:34 +0100
Stéphane Letz <letz(a)grame.fr> wrote:
On Linux, the semaphore is a bit faster than fifo.
On OSX we have in speed order : Mach semaphore, POSIX semaphore, fifo
I've not tested the pthread condition variables with pshared flag
set, it should probably work also on recent 2.6 kernel. But i guess
all primitives are built on top of futex APi on the end.
Stephane
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).
Flo
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 
6 Dec
6 Dec
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
7 Dec
7 Dec
4:31 a.m.
Le 7 déc. 05 à 02:00, Lee Revell a écrit :
On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt
wrote:
Do you have any test code you could share?
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. 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 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?
jackd (of jackdmp in "synch" mode) where the server waits for all
clients to finish in a given cycle require the used synchronization
primitive to have a "wait with time-out" operation. Fifo can do that
(using poll), Mach semaphore on OSX can do that, but POSIX named
semaphore not.
Do process shared mutexes/CVs have a "wait with time-out" operation.?
Thanks
Stephane
7:12 a.m.
On Wed, 7 Dec 2005 09:30:28 +0100
Stéphane Letz <letz(a)grame.fr> wrote:
jackd (of jackdmp in "synch" mode) where
the server waits for all
clients to finish in a given cycle require the used synchronization
primitive to have a "wait with time-out" operation. Fifo can do that
(using poll), Mach semaphore on OSX can do that, but POSIX named
semaphore not.
Do process shared mutexes/CVs have a "wait with time-out" operation.?
Well, there's
int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t
*mutex, const struct timespec *abstime);
(from man "pthread_cond_wait") which probably works with a condition
variable/mutex pair in shared memoryu, too.
But i don't know anything about any timing guarantees. I suppose POSIX
simply doesn't make any. Anyways, the precision of the timed wait is
probably implementation dependent.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
2:12 p.m.
On Wed, 2005-12-07 at 09:30 +0100, Stéphane Letz wrote:
Le 7 déc. 05 à 02:00, Lee Revell a écrit :
Sorry I can't share the code as it belongs to my employer. But I based
it on the "Interprocess Locking" example in this Solaris man page:
http://www.scit.wlv.ac.uk/cgi-bin/mansec?3T+mutex_lock
Lee
On Wed, 2005-11-02 at 11:48 +0100, Florian
Schmidt wrote:
Do you have any test code you could share?
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. 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).
31 Oct
31 Oct
12:36 p.m.
On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote:
On Sun, 30 Oct 2005 14:14:19 +0100
fons adriaensen <fons.adriaensen(a)skynet.be> wrote:
What manpage? I don't have those on my system.
Lee
On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian
Schmidt wrote:
Btw: i just discovered that pthread mutexes and condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be useful for jack, no?
pthread_condvar_setpshared()
pthread_mutexattr_setpshared()
Or do i misread that manpage? Oh i thought i read somewhere that when
pthread_cond_wait it is not
guaranteed that anyone actually signalled. Will do some more reading.
It can return on unix signals, so you have to test for EINTR.
I don't think it will wake up unexpectedly otherwise.
I'm thinking of rewriting the whole ITC object so it uses a
futex instead of the CV (that would also enable it to work
in shared memory across process boundaries), but then I really
need a lock free implementation for the linked lists.
I guess the required primitives are platform dependant.
Is their some library that provides them ?
3:42 p.m.
On Mon, 31 Oct 2005 10:57:46 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
Hi, i misspelled the first one:
pthread_condattr_setpshared
is the name. See here, too:
http://www.google.de/search?q=pthread_condattr_setpshared
SCNR ;)
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Btw: i just
discovered that pthread mutexes and condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be useful for jack, no?
pthread_condvar_setpshared()
pthread_mutexattr_setpshared()
Or do i misread that manpage?
What manpage? I don't have those on my system. 
3:39 p.m.
On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote:
Btw: i just discovered that pthread mutexes and
condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be useful for jack, no?
pthread_condvar_setpshared()
pthread_mutexattr_setpshared()
Yes, that's nice feature, I'm using that in my own apps. You can place
the objects in shared memory. It works with Linux 2.6 kernels and NPTL.
LinuxThreads doesn't have support for those (functions may exist, but
always return error).
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
7 Nov
7 Nov
2:12 p.m.
On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote:
Btw: i just discovered that pthread mutexes and
condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be useful for jack, no?
pthread_condvar_setpshared()
pthread_mutexattr_setpshared()
Or do i misread that manpage?
What manpage? Got a link? These are completely undocumented on my
Ubuntu 5.10 system. As a matter of fact, there is no documentation
whatsoever for NPTL - all the pthread man pages say "LinuxThreads" at
the bottom.
I'm really getting sick of the half-assed pthread support on Debian
based systems. Anyone got a recommendation for a better distro?
Lee
30 Oct
30 Oct
10:03 p.m.
fons adriaensen <fons.adriaensen(a)skynet.be> writes:
On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian
Schmidt wrote:
According to the POSIX spec the signalled thread is not guaranteed
that anything interesting has actually happened. It needs to check
its own status and (perhaps) wait a while longer.
Oh i thought i read somewhere that when
pthread_cond_wait it is not
guaranteed that anyone actually signalled. Will do some more reading.
It can return on unix signals, so you have to test for EINTR.
I don't think it will wake up unexpectedly otherwise. I'm thinking of rewriting the whole ITC object so
it uses a
futex instead of the CV (that would also enable it to work
in shared memory across process boundaries), but then I really
need a lock free implementation for the linked lists.
I guess the required primitives are platform dependant.
Is their some library that provides them ?
I believe there are no futexes in Linux 2.4 kernels. So, portable
applications need some other solution. That's the main advantage of
the pthread interfaces. They are not particularly wonderful, but they
are (relatively) portable.
--
joq
9:08 a.m.
On Sunday 30 October 2005 11:11, Florian Schmidt wrote:
Also the basic problem of signalling (in this case the disk thread that
there is work to do) still persists even with lockless ringbuffers. The
other thinkable approach would be to make the diskthread wakeup
regularly and check whether data is available in the ringbuffer. This is
nasty, too, and unsuitable for some situations.
Actually this approach can work very well, just make sure that the ring
buffers are sufficiently large and make the disk thread run at a lower RT
priority then any of the audio handling threads.
This is the approach taken in the rivendell broadcast automation system and it
seems to work fine even with the disk array mounted over NFS.
The trick is to remember that things like gain changes and effects can be
applied in the process thread, so there is no need for big latency even with
several seconds of disk buffer per file.
IIRC we wake up the disk thread at a few tens of HZ.
The downside is that it is kind of hard on memory usage when you need to
support lots of parallel playbacks.
Regards, Dan.
6985
days inactive
7024
days old
linux-audio-dev@lists.linuxaudio.org
32 comments
11 participants
participants (11)
-
Alfons Adriaensen -
Dan Mills -
Dave Robillard -
Florian Schmidt -
fons adriaensen -
Jack O'Quin -
Jussi Laako -
Lars Luthman -
Lee Revell -
Richard Spindler -
Stéphane Letz