Hello! On Sat, Dec 12, 2009 at 12:47 PM, Gabriel M. Beddingfield <[email protected]> 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
