25 Nov
2009
25 Nov
'09
5:27 p.m.
On Wed, 25 Nov 2009, Paul Davis wrote:
On Wed, Nov 25, 2009 at 12:10 PM, Kjetil S.
Matheussen
<k.s.matheussen(a)notam02.no> wrote:
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();
}
"Gabriel M. Beddingfield":
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.
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.