mikeash.com pyblog/friday-qa-2011-03-04-a-tour-of-osatomic.html comments

Steven - 2014-01-08 08:41:42

Wed, 08 Jan 2014 08:41:42 GMT

Brent's remark shows that cv qualifiers should never be written on the left of the declaration. Everybody's who has ever run into the infinitely optimized loop will agree, I'm sure.

David H - 2013-04-14 14:18:31

Sun, 14 Apr 2013 14:18:31 GMT

Can you provide a reference backing this: "Unfortunately, after some additional investigation, I discovered that OSQueue is not entirely thread safe and thus should not be used." I goggled around and did not trip on anything.

Sean M - 2011-03-16 14:16:52

Wed, 16 Mar 2011 14:16:52 GMT

Mike, nice article. Nitpick: the 64 bit variants, like OSAtomicAdd64, are available on PowerPC, but only ppc64, not ppc32.

Brent Priddy - 2011-03-12 18:40:37

Sat, 12 Mar 2011 18:40:37 GMT

Andre, the volatile keyword is the correct thing to use but in the example the volatile keyword is need to describe the pointer (I am not sure of Mike's usage of the struct to merit a volatile on the contents of the Struct as well). Mike, The while loop in your example if compiled with gcc and -O3 will be an infinite loop because of the compiler optimizing the assignment (thinking that the gStructure pointer does not change since the pointer is not volatile).

It should be:



Structure * volatile gStructure

This type of volatile usage is the way to solve this common problem with memory mapped io and aggressive optimizers.

mikeash - 2011-03-08 02:57:29

Tue, 08 Mar 2011 02:57:29 GMT

A minor quibble: reentrant and thread-safe are not synonyms. The former means that the code can safely be called on the same thread while it's already being called (for example, you can call back in from a callback, or a much worse case, you can safely call it from a signal handler) whereas the latter means multiple threads can hit code simultaneously. They're definitely related though, in that they both require similar concepts, and I think that any code which exclusively uses atomics for safety will automatically gain both properties.

That quibble aside, thanks for the historical view. I had no idea that these things went back that far.

jayc - 2011-03-07 23:40:33

Mon, 07 Mar 2011 23:40:33 GMT

Excellent article!.

As a historical note the IBM mainframe has had "CompareAndSwap" and "TestAndSet' and a few other related instructions as part of its machine instruction set architecture since day 1 (in the 1960s) The design of the OS in 1966 dictated that all system code be reentrant (eg. threadsafe) and it always has been. Even though the first machines were not multi-core the OS simulated it in the low level dispatcher. Later when multiple physical cores we added nothing had to change. Machine level semantics for memory barriers were added later but are part of the ISA today.

The point of all this history is that the concepts presented here are bedrock principles from the early days of computers. They have stood the test of time and provide the most efficient way to be threadsafe at a low level which can be, as the author states, very subtle and tricky.

mikeash - 2011-03-07 23:19:04

Mon, 07 Mar 2011 23:19:04 GMT

Thus providing an illustration of why I propose to use a memory barrier whenever in doubt. Thanks.

gparker - 2011-03-07 22:51:54

Mon, 07 Mar 2011 22:51:54 GMT

Technically, the barrier in the second thread should not be necassary, as the second read depends on the first. (The value of s needs to be available before the value of s->field2 can be retrieved.)

You know that you want the second read to depend on the first, but not all CPU architectures actually enforce that dependency without a barrier.

mikeash - 2011-03-07 04:23:16

Mon, 07 Mar 2011 04:23:16 GMT

It's needed for the first example in the memory barriers section to make sense, of course. Aside from that, it's more of a reminder than anything. It shouldn't make any difference either way, but it at least helps to point out the fact that this value is being used in tricky ways.

Andre Pang - 2011-03-07 04:12:21

Mon, 07 Mar 2011 04:12:21 GMT

I'm slightly surprised at your use of volatile, Mike. Given your excellent explanation of memory barriers and atomic operations here, why use volatile at all? I can't see it being needed in any of the examples above. Otherwise, awesome write-up, as always.

mikeash - 2011-03-07 01:31:32

Mon, 07 Mar 2011 01:31:32 GMT

I've been talking offline with a couple of anonymous readers and wanted to briefly summarize the important bits here.

First: if you're using garbage collection, the OSAtomic functions will bypass the mandatory GC write barriers when used with object pointers (or other strong pointers). If you are writing a GC app and want atomic operations on strong pointers, check out the objc_atomicCompareAndSwapPtr function and its friends in objc/objc-auto.h.

Second: there was a strong disagreement with my proposition to use a memory barrier when in doubt. It was proposed that, if you don't know whether you need a memory barrier, you probably need to think things through more rather than adding them just to be safe. You may have missed an important barrier otherwise. While I still hold my position, this is definitely a good point.

Steve Weller - 2011-03-04 23:46:51

Fri, 04 Mar 2011 23:46:51 GMT

The docs on OSAtomicCompareAndSwap32 are poor. They say it returns bool, yet do not document its value for different circumstances. You claim the return value is success. The docs claim that it "Returns the original value referenced by __theValue." I think that is left over from some hardware docs that are describing the actual swap that takes place between two values in memory in some implementations.

http://developer.apple.com/library/mac/#documentation/DriversKernelHardware/Reference/libkern_ref/OSAtomic_h/index.html%23//apple_ref/c/func/OSAtomicCompareAndSwap32

Vasi - 2011-03-04 23:32:17

Fri, 04 Mar 2011 23:32:17 GMT

Thanks for the Q&A. Folks should note that another good reference to the OSAtomic tools can be found in 'man atomic'.