Tue, 15 May 2001 09:34:16 -0700
Locking was a subject of much debate among the PortAudio folks when we
hammered out the API. It turns out that because the Mac is not really
multi-tasking, that there is no good way to lock out callbacks short of
turning off interrupts which is undesireable. Also, the consensus among
several developers was that for cross platform work, it was best to just
use atomic data structures when sharing info between the foreground and
the callback. I believe James McCartney first suggested this.
I have done the same in JSyn and found that atomic structures work fine.
I use an atomic FIFO for the foreground to background communication, and
an atomic singly linked list for background to foreground communication.
One trick in making a singly linked list atomic is to never drain it
completely because that is when a race condition can occur.
Also, I believe that the callback will not reenter itself in any of the
implementations so if you process the buffer in the callback then you
won't get called in the middle of processing.
Fuchs Hans wrote:
> I'm using portaudio on win32. It works well. But is there no lock-mechanism?
> I need to be sure, that the callback function isn't called while my program
> is processing the buffers.
> pa_lockstream( stream );
> do something;
> pa_unlockstream( stream );