Re: [linux-audio-dev] atomic xchg

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

Subject: Re: [linux-audio-dev] atomic xchg
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to loka   14 1999 - 22:36:51 EDT


>I'm just not convinced that this is the case. We're talking about
>data rates in the several-MB-per-sec range here, and I just don't
>believe that the latency of a thread sleep/wakeup is going to kill
>you, particularly not if your system is designed to use a sensible
>amount of buffering and POSIX RT scheduling priorities.

"sensible amount of buffering" ? I'm buffering 64 samples to provide
about 1ms of buffer time at a 48KHz sample rate, mono (half that if
the card is stereo, which it probably is). Going to sleep, waiting for
some other thread to get SIG<whatever-it-is-that-pthreads-is-using-this-week>
and wake up again to acquire the lock doesn't take anything like 1ms,
but it does take a substantial fraction of time i would otherwise have
spent doing computation on the 64 samples.

look, "spin-then-block" has been known for at least a decade to be the
right implementation of mutexes on MP systems. you can go back and dig
up Karlin's papers if you want to read more. it just so happens that
for some reason, pthreads doesn't provide pthread_mutex_spinlock(),
but insteads provides all the pieces you need to build it.

>Unless you have a smaller number of threads doing significant work
>than you have CPUs on the system, you'll have to take a break
>somewhere down the road anyway. If someone else holds a lock you
>need, well, I guess it's a good time to let another thread run.

yes, but *NOT* just because i want to check an event queue! certainly,
a SCHED_FIFO thread had better sleep at some point, but on an MP
system, its not right for this to happen just because it wants a
resource that has a lock around it. if the lock is only held for a
short time by another thread on another processor, then i want the
lock-acquiring thread to keep running until it gets the lock, and then
keep going after that.


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:59 EST