Back in the good old days of 68k, both pre/post pointer increments/decrements were more or less guaranteed to be atomic, due to the relatively general relationship between the stack pointer and other more generic address registers. As this behaviour is clearly a 68k artefact which may not procure the most efficient implementation on an alternate platform, would I be correct in assuming that the C specification makes no claims as to the "atomicity" of these operations.
Asked
Active
Viewed 451 times
2
-
None of the C specifications make any claim as to the atomicity of _any_ operations. – Nemo Jul 12 '11 at 18:09
-
1@Nemo: C1x guarantees atomicity of the new atomic operations. – ninjalj Jul 12 '11 at 18:11
-
i don't think there are any guarantees from C itself, no. (at least not if by pointer increment you mean something like ++ptr.) however, in many cases the actual result is indeed atomic. see http://stackoverflow.com/questions/879077/is-changing-a-pointer-considered-an-atomic-action-in-c for related discussion. – shelleybutterfly Jul 12 '11 at 18:12
-
May be you will find this answer helpful http://stackoverflow.com/questions/879077/is-changing-a-pointer-considered-an-atomic-action-in-c – Fedor Skrynnikov Jul 12 '11 at 18:15
-
@shelleybutterfly and Fedor: A lot of great information here; thanks for the links. – Taliadon Jul 12 '11 at 18:47
-
most welcome glad we could be of assistance! :) – shelleybutterfly Jul 12 '11 at 18:52
4 Answers
4
would I be correct in assuming that the C specification makes no claims as to the "atomicity" of these operations.
Yes. The current standard (both C99 and C89, IIRC) makes no claims about atomicity. That is definitely platform-specific, and probably depends on the compiler as well.
Why is it necessary for these operations to be atomic, if I may ask?
Rafe Kettler
- 75,757
- 21
- 156
- 151
-
Thanks for answer Rafe; just the information I was looking for. When we used to check the assembly output on the old 68k systems, an instruction like "move.l d1,(a3)+" was suitable for multi-process implementations due to the atomic nature of the write and pointer increment. As my assembly skills have diminished somewhat in the last decade, I was left wondering as to whether "*a3++ = d1" comes with any guarantees. – Taliadon Jul 12 '11 at 18:33
-
@Taliadon ahh, I see. Well, if you know that your code will only be compiled on certain architectures with certain OSes and certain compilers, then I guess you can check the assembly output, but I suspect that's more trouble than it's worth. – Rafe Kettler Jul 12 '11 at 18:58
-
LOL, I think you're right; after reading some additional information located on the forum, I really don't think my current skills are up to the task. It will be simpler for me to assume it isn't. Again, thanks for information, it is very much appreciated. – Taliadon Jul 12 '11 at 19:11
1
C standard have no atomic operations at all. However there are some GCC built-ins described here, and there are some in C++0X stanard. And you always can use POSIX or other multithreading library or inline assembler in your code.
qoyllur
- 29
- 2
0
Regardless of what the standard specifies, 80x86 pointer arithmetic and assignments on "huge" pointers was not atomic, but pointer increments and assignments are apt to be composed of an atomic read and an atomic write on all platforms where "int" is 32 bits or larger or where a pointer is the same size as an 'int' (some embedded platforms have things like 16 bit int but 24-bit pointer). The read-modify-write sequence is almost never going to form an atomic unit on any multi-processor architecture, however, unless one takes explicit measures to make it behave as such.
supercat
- 77,689
- 9
- 166
- 211
0
There is never a guarantee of atomicity unless explicitly documented. Under the current C standard, that means that no portable code can guarantee atomicity -- atomic operators are necessarily platform-specific.
As @ninjalj notes in his comment, C1x will add atomic operators.
Stephen Canon
- 103,815
- 19
- 183
- 269