[PATCH] new jack_rdlock_graph () for null_cycle-less qjackctl client connections polling

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

[PATCH] new jack_rdlock_graph () for null_cycle-less qjackctl client connections polling

Karsten Wiese
Hi,

hope the subject says it all ;-)
The null-cycles caused by qjackctl's client connections polling
happen here with ccrma versions qjackctl 0.2.22 and jackd 0.103.0.

Patch against 0.103.0 replaces
        pthread_mutex_t client_lock;
by
        pthread_rwlock_t client_lock;
, updates all existing users and introduces 2 new functions
        void jack_rdlock_graph ();
and
        jack_try_rdlock_graph ();

tested on fedora 7, no null_cycles anymore caused by qjackctl.
That is, as long as the graph stays unchanged of course.
Hope it applies to trunk as well.

kind regards, signed-off-by
      Karsten

--------------------------------------------------------------------->

diff -pur jack-audio-connection-kit-0.103.0_orig/jack/engine.h jack-audio-connection-kit-0.103.0/jack/engine.h
--- jack-audio-connection-kit-0.103.0_orig/jack/engine.h 2007-04-01 00:26:35.000000000 +0200
+++ jack-audio-connection-kit-0.103.0/jack/engine.h 2007-11-03 12:32:14.000000000 +0100
@@ -76,7 +76,7 @@ struct _jack_engine {
 
     /* engine serialization -- use precedence for deadlock avoidance */
     pthread_mutex_t request_lock; /* precedes client_lock */
-    pthread_mutex_t client_lock;
+    pthread_rwlock_t client_lock;
     pthread_mutex_t port_lock;
     int    process_errors;
     int    period_msecs;
@@ -176,21 +176,26 @@ extern jack_timer_type_t clock_source;
 extern jack_client_internal_t *
 jack_client_internal_by_id (jack_engine_t *engine, jack_client_id_t id);
 
+static inline void jack_rdlock_graph (jack_engine_t* engine) {
+ DEBUG ("acquiring graph lock");
+ pthread_rwlock_rdlock (&engine->client_lock);
+}
+
 static inline void jack_lock_graph (jack_engine_t* engine) {
  DEBUG ("acquiring graph lock");
- pthread_mutex_lock (&engine->client_lock);
+ pthread_rwlock_wrlock (&engine->client_lock);
 }
 
-static inline int jack_try_lock_graph (jack_engine_t *engine)
+static inline int jack_try_rdlock_graph (jack_engine_t *engine)
 {
  DEBUG ("TRYING to acquiring graph lock");
- return pthread_mutex_trylock (&engine->client_lock);
+ return pthread_rwlock_tryrdlock (&engine->client_lock);
 }
 
 static inline void jack_unlock_graph (jack_engine_t* engine)
 {
  DEBUG ("releasing graph lock");
- pthread_mutex_unlock (&engine->client_lock);
+ pthread_rwlock_unlock (&engine->client_lock);
 }
 
 static inline unsigned int jack_power_of_two (unsigned int n)
diff -pur jack-audio-connection-kit-0.103.0_orig/jackd/clientengine.c jack-audio-connection-kit-0.103.0/jackd/clientengine.c
--- jack-audio-connection-kit-0.103.0_orig/jackd/clientengine.c 2007-04-01 00:26:37.000000000 +0200
+++ jack-audio-connection-kit-0.103.0/jackd/clientengine.c 2007-11-03 14:27:14.000000000 +0100
@@ -279,7 +279,7 @@ jack_client_by_name (jack_engine_t *engi
  jack_client_internal_t *client = NULL;
  JSList *node;
 
- jack_lock_graph (engine);
+ jack_rdlock_graph (engine);
 
  for (node = engine->clients; node; node = jack_slist_next (node)) {
  if (strcmp ((const char *) ((jack_client_internal_t *)
@@ -300,7 +300,7 @@ jack_client_id_by_name (jack_engine_t *e
  jack_client_id_t id = 0; /* NULL client ID */
  JSList *node;
 
- jack_lock_graph (engine);
+ jack_rdlock_graph (engine);
 
  for (node = engine->clients; node; node = jack_slist_next (node)) {
  if (strcmp ((const char *) ((jack_client_internal_t *)
@@ -921,7 +921,7 @@ jack_intclient_name_request (jack_engine
 {
  jack_client_internal_t *client;
 
- jack_lock_graph (engine);
+ jack_rdlock_graph (engine);
  if ((client = jack_client_internal_by_id (engine,
   req->x.intclient.id))) {
  strncpy ((char *) req->x.intclient.name,
diff -pur jack-audio-connection-kit-0.103.0_orig/jackd/engine.c jack-audio-connection-kit-0.103.0/jackd/engine.c
--- jack-audio-connection-kit-0.103.0_orig/jackd/engine.c 2007-04-01 00:26:37.000000000 +0200
+++ jack-audio-connection-kit-0.103.0/jackd/engine.c 2007-11-03 14:28:25.000000000 +0100
@@ -1314,7 +1314,7 @@ handle_external_client_request (jack_eng
 
  DEBUG ("HIT: before lock");
 
- jack_lock_graph (engine);
+ jack_rdlock_graph (engine);
 
  DEBUG ("HIT: before for");
 
@@ -1598,7 +1600,7 @@ jack_engine_new (int realtime, int rtpri
  jack_engine_reset_rolling_usecs (engine);
  engine->max_usecs = 0.0f;
 
- pthread_mutex_init (&engine->client_lock, 0);
+ pthread_rwlock_init (&engine->client_lock, 0);
  pthread_mutex_init (&engine->port_lock, 0);
  pthread_mutex_init (&engine->request_lock, 0);
 
@@ -1960,7 +1962,7 @@ jack_run_one_cycle (jack_engine_t *engin
  consecutive_excessive_delays = 0;
  }
 
- if (jack_try_lock_graph (engine)) {
+ if (jack_try_rdlock_graph (engine)) {
  /* engine can't run. just throw away an entire cycle */
  driver->null_cycle (driver, nframes);
  return 0;
@@ -3537,7 +3539,7 @@ jack_do_get_port_connections (jack_engin
  int ret = -1;
  int internal = FALSE;
 
- jack_lock_graph (engine);
+ jack_rdlock_graph (engine);
 
  port = &engine->internal_ports[req->x.port_info.port_id];
 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] new jack_rdlock_graph () for null_cycle-less qjackctl client connections polling

Rui Nuno Capela
Karsten Wiese wrote:
> Hi,
>
> hope the subject says it all ;-)

duh, could this be related in anyway to an issue some users were
reporting about having continuous 100%cpu loads (no, not %dsp load)
after starting jackd from qjackctl 0.3.1a (unstable-qt4) ?

iirc, some kind of poll()-hosing has been spotted through `strace
qjackctl` but all suspicions have gone towards libqt4, not jackd ...

would the guys who reported that qjackctl behavior raise their hands and
kindly volunteer to try this one out? please?

i have not way to verify whether it helps, as i can't reproduce the
qjackctl 100%cpu consumption issue myself.


> The null-cycles caused by qjackctl's client connections polling
> happen here with ccrma versions qjackctl 0.2.22 and jackd 0.103.0.
>
> Patch against 0.103.0 replaces
> pthread_mutex_t client_lock;
> by
> pthread_rwlock_t client_lock;
> , updates all existing users and introduces 2 new functions
> void jack_rdlock_graph ();
> and
> jack_try_rdlock_graph ();
>
> tested on fedora 7, no null_cycles anymore caused by qjackctl.
> That is, as long as the graph stays unchanged of course.
> Hope it applies to trunk as well.
>
> kind regards, signed-off-by
>       Karsten
>
> --------------------------------------------------------------------->
>
> diff -pur jack-audio-connection-kit-0.103.0_orig/jack/engine.h jack-audio-connection-kit-0.103.0/jack/engine.h
> --- jack-audio-connection-kit-0.103.0_orig/jack/engine.h 2007-04-01 00:26:35.000000000 +0200
> +++ jack-audio-connection-kit-0.103.0/jack/engine.h 2007-11-03 12:32:14.000000000 +0100
> @@ -76,7 +76,7 @@ struct _jack_engine {
>  
>      /* engine serialization -- use precedence for deadlock avoidance */
>      pthread_mutex_t request_lock; /* precedes client_lock */
> -    pthread_mutex_t client_lock;
> +    pthread_rwlock_t client_lock;
>      pthread_mutex_t port_lock;
>      int    process_errors;
>      int    period_msecs;
> @@ -176,21 +176,26 @@ extern jack_timer_type_t clock_source;
>  extern jack_client_internal_t *
>  jack_client_internal_by_id (jack_engine_t *engine, jack_client_id_t id);
>  
> +static inline void jack_rdlock_graph (jack_engine_t* engine) {
> + DEBUG ("acquiring graph lock");
> + pthread_rwlock_rdlock (&engine->client_lock);
> +}
> +
>  static inline void jack_lock_graph (jack_engine_t* engine) {
>   DEBUG ("acquiring graph lock");
> - pthread_mutex_lock (&engine->client_lock);
> + pthread_rwlock_wrlock (&engine->client_lock);
>  }
>  
> -static inline int jack_try_lock_graph (jack_engine_t *engine)
> +static inline int jack_try_rdlock_graph (jack_engine_t *engine)
>  {
>   DEBUG ("TRYING to acquiring graph lock");
> - return pthread_mutex_trylock (&engine->client_lock);
> + return pthread_rwlock_tryrdlock (&engine->client_lock);
>  }
>  
>  static inline void jack_unlock_graph (jack_engine_t* engine)
>  {
>   DEBUG ("releasing graph lock");
> - pthread_mutex_unlock (&engine->client_lock);
> + pthread_rwlock_unlock (&engine->client_lock);
>  }
>  
>  static inline unsigned int jack_power_of_two (unsigned int n)
> diff -pur jack-audio-connection-kit-0.103.0_orig/jackd/clientengine.c jack-audio-connection-kit-0.103.0/jackd/clientengine.c
> --- jack-audio-connection-kit-0.103.0_orig/jackd/clientengine.c 2007-04-01 00:26:37.000000000 +0200
> +++ jack-audio-connection-kit-0.103.0/jackd/clientengine.c 2007-11-03 14:27:14.000000000 +0100
> @@ -279,7 +279,7 @@ jack_client_by_name (jack_engine_t *engi
>   jack_client_internal_t *client = NULL;
>   JSList *node;
>  
> - jack_lock_graph (engine);
> + jack_rdlock_graph (engine);
>  
>   for (node = engine->clients; node; node = jack_slist_next (node)) {
>   if (strcmp ((const char *) ((jack_client_internal_t *)
> @@ -300,7 +300,7 @@ jack_client_id_by_name (jack_engine_t *e
>   jack_client_id_t id = 0; /* NULL client ID */
>   JSList *node;
>  
> - jack_lock_graph (engine);
> + jack_rdlock_graph (engine);
>  
>   for (node = engine->clients; node; node = jack_slist_next (node)) {
>   if (strcmp ((const char *) ((jack_client_internal_t *)
> @@ -921,7 +921,7 @@ jack_intclient_name_request (jack_engine
>  {
>   jack_client_internal_t *client;
>  
> - jack_lock_graph (engine);
> + jack_rdlock_graph (engine);
>   if ((client = jack_client_internal_by_id (engine,
>    req->x.intclient.id))) {
>   strncpy ((char *) req->x.intclient.name,
> diff -pur jack-audio-connection-kit-0.103.0_orig/jackd/engine.c jack-audio-connection-kit-0.103.0/jackd/engine.c
> --- jack-audio-connection-kit-0.103.0_orig/jackd/engine.c 2007-04-01 00:26:37.000000000 +0200
> +++ jack-audio-connection-kit-0.103.0/jackd/engine.c 2007-11-03 14:28:25.000000000 +0100
> @@ -1314,7 +1314,7 @@ handle_external_client_request (jack_eng
>  
>   DEBUG ("HIT: before lock");
>  
> - jack_lock_graph (engine);
> + jack_rdlock_graph (engine);
>  
>   DEBUG ("HIT: before for");
>  
> @@ -1598,7 +1600,7 @@ jack_engine_new (int realtime, int rtpri
>   jack_engine_reset_rolling_usecs (engine);
>   engine->max_usecs = 0.0f;
>  
> - pthread_mutex_init (&engine->client_lock, 0);
> + pthread_rwlock_init (&engine->client_lock, 0);
>   pthread_mutex_init (&engine->port_lock, 0);
>   pthread_mutex_init (&engine->request_lock, 0);
>  
> @@ -1960,7 +1962,7 @@ jack_run_one_cycle (jack_engine_t *engin
>   consecutive_excessive_delays = 0;
>   }
>  
> - if (jack_try_lock_graph (engine)) {
> + if (jack_try_rdlock_graph (engine)) {
>   /* engine can't run. just throw away an entire cycle */
>   driver->null_cycle (driver, nframes);
>   return 0;
> @@ -3537,7 +3539,7 @@ jack_do_get_port_connections (jack_engin
>   int ret = -1;
>   int internal = FALSE;
>  
> - jack_lock_graph (engine);
> + jack_rdlock_graph (engine);
>  
>   port = &engine->internal_ports[req->x.port_info.port_id];
>  
>

cheers.
--
rncbc aka Rui Nuno Capela
[hidden email]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] new jack_rdlock_graph () for null_cycle-less qjackctl client connections polling

Jussi Laako-2
Rui Nuno Capela wrote:
> would the guys who reported that qjackctl behavior raise their hands and
> kindly volunteer to try this one out? please?

Did not help on my system (SUSE 10.3 x86-64)...


BR,

        - Jussi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] new jack_rdlock_graph () for null_cycle-less qjackctl client connections polling

Rui Nuno Capela
Jussi Laako wrote:
> Rui Nuno Capela wrote:
>> would the guys who reported that qjackctl behavior raise their hands and
>> kindly volunteer to try this one out? please?
>
> Did not help on my system (SUSE 10.3 x86-64)...
>

interesting, opensuse 10.3 i586 (x86-32) here and as said i can't
reproduce the 100%cpu qjackctl behavior. could it be x86-64 issue after all?

seeya
--
rncbc aka Rui Nuno Capela
[hidden email]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] new jack_rdlock_graph () for null_cycle-less qjackctl client connections polling

juuso.alasuutari (Bugzilla)
On Monday 05 November 2007 00:35:31 Rui Nuno Capela wrote:

> Jussi Laako wrote:
> > Rui Nuno Capela wrote:
> >> would the guys who reported that qjackctl behavior raise their hands and
> >> kindly volunteer to try this one out? please?
> >
> > Did not help on my system (SUSE 10.3 x86-64)...
>
> interesting, opensuse 10.3 i586 (x86-32) here and as said i can't
> reproduce the 100%cpu qjackctl behavior. could it be x86-64 issue after
> all?

I'm the other guy seeing the high CPU load, but my system is x86. (It's a Core
2 Duo but the install is 32-bit.)

I'll try the patch tonight and report back.

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel