Re: Lock-free protocols?
Re: Lock-free protocols?
- Subject: Re: Lock-free protocols?
- From: Herbie Robinson <email@hidden>
- Date: Mon, 29 Apr 2002 02:09:36 -0400
On Monday, April 22, 2002, at 01:04 AM, Jeremy Cooper wrote:
I've seen a lot of discussion on this list about the perils of
synchronizing IOProc threads with worker threads using locks. Several
people have mentioned that there are ways to transfer data safely between
IOProc threads and other lower-priority threads without using locks, yet
no one has actually shown how it is done.
Can someone show some code snippets for 'lock-free' buffer passing?
Well, I got curious about this too, so I figured it out (I think!)
and put together an example.
http://www.snoize.com/Code/PlayBufferedAIFF.tar.gz
This is a command-line tool which plays an AIFF file through the
default audio output. It uses a ring buffer to moderate between
between a thread which reads data from the file, and the CoreAudio
playback thread. The ring buffer doesn't use explicit locking (it
relies on atomic reads and writes by the processor) so the playback
thread will not block when it shouldn't.
Note: I have only tested this on a single-processor machine, so my
assumptions about atomicity on SMP machines could turn out to be
completely wrong. It wouldn't be the first time SMP bit someone. If
anyone could try it and let me know your results, I would appreciate
it.
I didn't actually try it (no AIFF files on this machine and the one
that's got them is doing a 3 hour bounce right now), but it looks
good. The gotcha with circular buffering is hangs because it's
really hard to atomically tell that the other end is blocked. You
get around that by using sleeps for scheduling (which works great if
the data arrives at a constant rate). The sleep technique is good,
BTW, because it should get less scheduling latency in addition to
avoiding the nasty memory ordering issues involved when one tries to
schedule based on the queue emptying or filling up...
That said--it works pretty well on my machine. With the default
parameters, I don't get dropouts even with lots of other stuff going
on in the background, dragging big windows all over the place, etc,
and the CPU usage seems to be negligible compared to the CoreAudio
overhead. I'm sure the parameters could use some further tuning, of
course.
The ring buffer also uses a neat trick with Mach VM mapping, which
makes dealing with the wraparound a whole lot easier and faster.
Give it a try... comments and corrections are appreciated.
--
Kurt Revis
email@hidden
That neat ring buffer trick could cause nasty performance issues on
some hardware: Pa-risc, for example, doesn't like to see the same
physical address at two different virtual addresses unless the
virtual addresses are separated by some huge amount (it's supposed to
work, but they promise performance degradation -- probably TLB
ping-ponging). Some other machines only allow shared physical pages
at the same virtual address (in different processes): If the
hardware doesn't support this, then the OS is going to have to be
constantly changing the mapping. If you are trying to write
transportable code, using that trick is probably not a good idea.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.