Re: [LAD] Atomic Operations

Hello!

On Sat, Dec 12, 2009 at 12:47 PM, Gabriel M. Beddingfield
<gabriel@teuton.org> wrote:
>
> Alexander Sandler, on his blog, wrote a couple of good articles on the
> subject:
>
>    "Do you need a mutex to protect an int?"
>    http://www.alexonlinux.com/do-you-need-mutex-to-protect-int

I didn't read the others, but I looked at this one and I think it's
important to point out some problems with it. He is claiming that you
cannot increment an integer atomically, which is true, but this
doesn't mean that the reads and writes, by themselves, are not atomic
operations.

If you read a register while another core is writing to that register
and this gives you the _wrong value_, then the reads and writes
themselves are not atomic. (For example, a byte of the integer is
changed before the read operation completes.) As far as I understand
this doesn't happen as long as you stick to the word size of the
architecture. (Anyone please correct me if I'm wrong about that.)

However, if a write to a register is guaranteed to be completed before
any other reads can proceed, then reads and writes to an integer are
considered atomic. This doesn't mean that incrementing that value is
atomic, because it consists of 3 operations, as pointed out on that
page in the 3:31 comment by David Brown.

In the example given by Alex he points out that the correct sum is not
given after concurrently incrementing a counter in 4 threads one
million times. But he doesn't seem to consider that the reason is
because the _reads_ to the counter may be safely performed in
parallel, so several threads could be incrementing the same value and
overwriting each other's new values.

In any case, as long as you're guaranteed not to read _garbage_,
atomic operations can be a great way to avoid locking, if you use them
very carefully. They are, after all, needed to implement semaphores
and spinlocks in the first place. However you can also use them to
implement circular FIFOs for example, which is a trick used all the
time in audio as well as in kernel programming.

One thing I'd like to know more is what the actual penalty for using
atomic operations is. I think it's less than using locks, (again
depending on what you're doing), but on the hardware level I imagine
it causes stalls in the processor's pipeline. (Due to memory
barriers.) I don't know enough about microprocessor design to say
more about it.

Steve
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Dec 15 00:15:02 2009