[linux-audio-dev] mutex madness

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] mutex madness
From: est_AT_hyperreal.org
Date: ke syys   29 1999 - 16:34:29 EDT


Paul Barton-Davis discourseth:
>
> If an automation object decides that its time to post a parameter
> change, and we want the UI object to notice it, it is *NOT ENOUGH* to
> either (1) put the event on a queue or (2) execute a callback to the
> UI code. In the case of (1), we have to grab the mutex around the
> queue, which may or may not be a good idea, depending on your timing
> constraints. In the case of (2), you have to implement a way to
> execute a callback in the UI thread, not the thread posting the event.
>
> There are some workarounds to this, such as always running the
> automation code within the UI thread, and/or being very careful to
> hold queue-protecting mutexes for a very, very short time. But even
> so, you have to be careful.

Indeed. pthread mutexes aren't `fair'. If the ui gets 500 events
behind it's entirely possible it will hog the mutex as it wraps a lock
around each pop while the dsp is trying to push one event.

However, if you build a fair mutex from pthread mutexes and condition
variables, wouldn't the mutex-protected-queue approach be reliable?

Eric


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST