18

Inspired by this question: In Complexity Analysis why is ++ considered to be 2 operations?

Take the following psuedo code:

class test
{
   int _counter;
   void Increment()
   {
     _counter++;
   } 
}

Would this be considered thread safe on an x86 architechure? Further more are the Inc / Dec assembly instructions thread safe?

Community
  • 1
  • 1
JoshBerke
  • 66,142
  • 25
  • 126
  • 164
  • jit compiler? of which platform? – chakrit Jan 14 '09 at 16:04
  • Are we talking Java or C# or something else? – Michael Myers Jan 14 '09 at 16:04
  • 5
    This question is definitely not language-agnostic! It depends a lot on which language and/or platform you're using! – Joachim Sauer Jan 14 '09 at 16:21
  • Sorry I mean to leave the jit part of the question... – JoshBerke Jan 14 '09 at 17:38
  • Does this answer your question? [Can num++ be atomic for 'int num'?](https://stackoverflow.com/questions/39393850/can-num-be-atomic-for-int-num) – Peter Cordes May 14 '20 at 14:09
  • @PeterCordes similar but not identical. The other question is targeting C++. Not to mention this question/answer is a lot simpler – JoshBerke May 15 '20 at 14:26
  • I understand the operator is not atomic and thus safe but can data race on it lead to "crazy" values? I.e. what if starting with i=100 and we have one writer and one reader that might data race on i++. I.e. the writer will increment and the reader will try to read somewhere within the increment assembly code block. Is there any other possible outcome for reader other than i=100 or i>100? I mean is there any case where the reader can get for example i<100? If not can we say that this -despite the data race- is eventually consistent? – big_in_japan Sep 15 '22 at 09:06

2 Answers2

33

No, incrementing is not thread-safe. Neither are the INC and DEC instructions. They all require a load and a store, and a thread running on another CPU could do its own load or store on the same memory location interleaved between those operations.

Some languages have built-in support for thread synchronization, but it's usually something you have to ask for, not something you get automatically on every variable. Those that don't have built-in support usually have access to a library that provides similar functionality.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
15

In a word, no.

You can use something like InterlockedIncrement() depending on your platform. On .NET you can use the Interlocked class methods (Interlocked.Increment() for example).

A Rob Kennedy mentioned, even if the operation is implemented in terms of a single INC instruction, as far as the memory is concerned a read/increment/write set of steps is performed. There is the opportunity on a multi-processor system for corruption.

There's also the volatile issue, which would be a necessary part of making the operation thread-safe - however, marking the variable volatile is not sufficient to make it thread-safe. Use the interlocked support the platform provides.

This is true in general, and on x86/x64 platforms certainly.

Community
  • 1
  • 1
Michael Burr
  • 333,147
  • 50
  • 533
  • 760