6

How are atomic operations made thread-safe? I've read about the subject in Wikipedia's article on thread-safety. But the article didn't really explain the process behind the scenes. In other words, why can't an "atomic" operation executed by a thread A be interrupted by a thread B?

assylias
  • 321,522
  • 82
  • 660
  • 783
ayoubuntu
  • 425
  • 1
  • 8
  • 13
  • 7
    Eh... because it is _atomic_, as in the smallest possible unit or _indivisible_... – K-ballo Jan 17 '13 at 01:01
  • And they don't make your program magically thread-safe... – zch Jan 17 '13 at 01:06
  • @zch True, but the author did not state that anywhere in his question as far as I can see. – Maarten Bodewes Jan 17 '13 at 01:09
  • @owlstead, the title seems to imply that, but maybe it's just me. – zch Jan 17 '13 at 01:11
  • 3
    Closed? Really? Do people even _read_ the reasons behind things like "not a real question"? :-) This seems to be none of "ambiguous, vague, incomplete, overly broad, or rhetorical". – paxdiablo Jan 17 '13 at 01:17
  • @paxdiablo The "i'm wondering why atomic operations are considered thread-safe" is somewhat confusing. But voting to reopen I agree. – assylias Jan 17 '13 at 01:19
  • 1
    @assylias - You have a (small) point. But I'd simply put that down to the OP not having a good command of English. We try to make allowances for that. (And you are free to edit the Question's title to remove the confusion ...) – Stephen C Jan 17 '13 at 01:22

3 Answers3

8

An atomic operation will either be completed or not done at all. Other threads will not be able to see the operation "in progress" -- it will never be viewed in a partially complete state. This is what the word "atomic" means in this context.

The behind-the-scenes magic for making that true will vary from implementation to implementation. For the purposes of your concurrency design, all you can rely on is that all-or-nothing guarantee on execution.

Mel Nicholson
  • 3,225
  • 14
  • 24
  • I don't think that's what _atomic_ means in this context, in this context operations are always completed... but this is off-topic anyway – K-ballo Jan 17 '13 at 01:05
  • 1
    @K-ballo, that may be a misunderstanding of the answer's intent. I don't think myself that it was suggesting the commit/rollback semantics of relational databases. The atomic operation _is_ either not done (before) or done (after), there is no possibility of thread-switching halfway through the operation. – paxdiablo Jan 17 '13 at 01:13
  • @MelNicholson: Yeap, now I see what you meant – K-ballo Jan 17 '13 at 01:14
  • @Mel Nicholson Thanks bro that's what i was aiming. – ayoubuntu Jan 17 '13 at 01:20
6

But they didn't really explain the process behind the scenes, in other words, why an atomic operation executed by a thread A couldn't be interupted by a thread B ?

The reason they don't explain what happens behind the scenes is that that is highly implementation specific. For instance, it depends on the hardware instructions available to do that kind of thing on the implementation platform.

But you shouldn't need to worry about that. You shouldn't care how atomicity (e.g. non-interuptability) is implemented. You should simply rely on the guarantees that are provided by the AtomicXxx class APIs that certain operations will behave in an atomic fashion, and build your higher-level thread safety based on those guarantees.

But note that the atomicity property of AtomicXxx classes only applies to the individual operations. A sequence of AtomicXxx operations will not be performed atomically, and hence won't automatically be thread-safe.

In short, if you use AtomicXxx classes to implement thread-safety, you need to understand what you are doing.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
1

Compare-and-set is one machine instruction, so it won't be interrupted.

In that sense, all machine instructions are atomic, which is not very interesting. For example, a simple write is always atomic.

"Interesting" atomic operations are those that intuitively consist of 2 or more steps, but implemented as one indivisible step, for example, compare-and-set; volatile r/w of long on 32 bit machine.

irreputable
  • 44,725
  • 9
  • 65
  • 93