On Wed, 25 Nov 2009, Paul Davis wrote:
> On Wed, Nov 25, 2009 at 12:10 PM, Kjetil S. Matheussen > <[email protected]> wrote: >> >> "Gabriel M. Beddingfield": >>> So you see, by using a mutex... you have to consider >>> those sections of code as being a part of your >>> process() function. >> >> Great explanation, but you forgot to explicitly mention >> that those sections of code also has to run with higher >> or equal priority as the jack process to avoid priority >> inversion. > > and since (IIRC) linux/pthreads don't do this, you basically should > never use a lock in this fashion at all! > > pthread_mutex_trylock() is fine. just avoid pthread_mutex_lock(). this > does require that you have some fallback strategy: what to do if you > can't take the lock. > But sometimes it makes sense to temporarily boost performance of non-realtime threads, like this: non_realtime_thread_visiting(){ old_prio = get_prio(); set_prio(jack_prio);{ pthread_mutex_lock(){ <do realtime-safe stuff> }pthread_mutex_unlock(); }set_prio(old_prio) } jack_process_thread(){ pthread_mutex_lock(){ <do realtime-safe stuff> }pthread_mutex_unlock(); } _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
