jack_activate race

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

jack_activate race

Ron Cococcia
Hello,

I've been working with a program that has multiple music players.  This
program is threaded, and uses JACK for output control.  I had been
testing the application, mainly by restarting it a lot, and seeing how
it behaves under heavy system load.  This test uses 2 media players,
each with 2 outputs.  I connect the first player to system:playback_[12]
and the second to system:playback_[34].  Normally, jack_lsp will show
the players properly connected to the system playback ports.

On a few occasions, however, I found that only the first player was
connected, and the second player wouldn't connect.  Trying to use
jack_connect to make the connection failed with "cannot connect ports
owned by inactive clients".  Using gdb, I traced each of the threads,
and found one that was still stuck on jack_activate, in particular
waiting for pthread_cond_wait to return.  Quickly looking at the code
for jack_activate, I think see the problem.  If the first thread goes to
activate, it initializes the static mutex and condition, then does some
work (starting a thread, etc).  If the second thread comes in while that
is being done, it will reinitialize the mutex and condition and do the
same work.  But only 1 of the threads gets to properly return, the other
stuck in limbo.

I changed the mutex and condition to use static initializers (patch
included), and so far I have not been able to reproduce the problem (2
hours of repeated startup tests).  Does this look like a reasonable fix?

Thanks,
Ron

--- libjack/client.c.orig 2008-03-24 10:12:38.000000000 -0400
+++ libjack/client.c 2008-03-24 10:13:45.000000000 -0400
@@ -61,8 +61,8 @@
 #include <sysdeps/pThreadUtilities.h>
 #endif
 
-static pthread_mutex_t client_lock;
-static pthread_cond_t  client_ready;
+static pthread_mutex_t client_lock = PTHREAD_MUTEX_INITIALIZER;
+static pthread_cond_t  client_ready = PTHREAD_COND_INITIALIZER;
 
 static int
 jack_client_close_aux (jack_client_t *client);
@@ -1949,9 +1949,6 @@
 
  if (client->first_active) {
 
- pthread_mutex_init (&client_lock, NULL);
- pthread_cond_init (&client_ready, NULL);
-
  pthread_mutex_lock (&client_lock);
 
  if (jack_start_thread (client)) {

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack_activate race

Paul Davis

On Mon, 2008-03-24 at 11:00 -0400, Ron Cococcia wrote:
> Hello,
>
> I've been working with a program that has multiple music players.

JACK (or at least jackd + its libjack) are not written to support
multiple JACK threads in the same address space. if it works, its an
accident and there is no assurance that some other related bug is not
waiting in the wings.

Its possible that jackdmp and JACK 2.0 may change this state of affairs.

--p




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack_activate race

Kjetil Matheussen
In reply to this post by Ron Cococcia


Paul Davis:

>
> On Mon, 2008-03-24 at 11:00 -0400, Ron Cococcia wrote:
>> Hello,
>>
>> I've been working with a program that has multiple music players.
>
> JACK (or at least jackd + its libjack) are not written to support
> multiple JACK threads in the same address space. if it works, its an
> accident and there is no assurance that some other related bug is not
> waiting in the wings.
>

That's interesting. I may have misunderstood what you mean, but
just in case; Snd has one jack thread for sndlib and one jack
thread for snd-rt (using two clients), and I can't remember
any issues with jack doing so, neither with jackd nor jackdmp.
Is it just an accident that it actually works? Does jackd store
thread related data in global variables and not in the jack_client
structure?


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel