Subject: Re: [linux-audio-dev] Audio engine stuff
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke helmi 16 2000 - 21:19:49 EST
Some clarifications to Benno's ringbuffer explanation, mostly to do
with what locks are.
>the writer alway tries to keep the buffer as full as possible,
>(by computing the free space in the buffer)
>while the reader just reads the data at constant rate.
there is no reason for the rate to be constant. the reader reads
whenever it wants to, and reads as much it wants to of the data
currently available.
>lock-free : you read and maniplulate the buffer pointers ( write
>pointer, read pointer) in a way that you do not need any spinlocks.
to be more precise: you do not need locks (not spinlocks) to achieve
acceptable operation of the ringbuffer. Sometimes, the writer will
write less than it could have. you can avoid this by using a lock, in
which case, the amount written by the writer is always the maximum
possible. the difference is *usually* small, so lock free is *usually*
OK. in general, if the read and write sizes are about the same, or the
write size exceeds the read size, lock free is good.
>Why do we want to avoid spinlocks ?
This really is: Why do we want to avoid locks ?
locks come in two varieties: spin locks and blocking locks. pthreads,
for example, does not provide spin locks (though it does provide the
pieces needed to build them). a blocking lock checks to see if the
lock is held, and if it is, the calling thread blocks (goes to sleep)
until the lock becomes free and the thread is the lucky one to be
notified of that fact.
with a spin lock, you simply sit on the processor and keep checking
whether the lock is free. you cannot use spinlocks effectively on
uni-processor machines. even on MP machines, its not common to use
pure spinlocks, but instead most people use "spin-then-block", where
you sit in a tight loop checking the lock status for a short time
(roughly 50% of the interthread context switch time), and then block
if it is not free.
spin-then-block is very useful on MP systems where the lock protects a
resource whose use is always very short lived. a trivial example
would be protecting a single arithmetic operation on a variable. the
operation takes just a couple of instructions, and then the lock is
freed. if another thread is running on another processor, it makes
more sense to spin for a little bit if the lock is held, because the
chances are that it will be free very, very soon.
the quasimodo-associated "libpbd" contains code for
pthread_mutex_spinlock(), which implements a calibrated
spin-then-block. by calibrated, i mean that it will never spin on a UP
machine, and will spin for roughly 50% of the inter-thread context
switch time on an MP machine. there is an additional function that
does the calibration; if not called, or its a UP system, then
pthread_mutex_spinlock is almost exactly identical to
pthread_mutex_lock in execution time.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST