-2

From lot of threads, like this one, I have found that C# int/float are thread safe. But I have seen lot of developers using Interlocked.Increment/CompareExchage for multi-threaded application. Any one can tell me the reason for using these constructs. Update: I am aware about these constructs. I just wanted to ask If int is thread safe the why we need these constructs?

Community
  • 1
  • 1
Imran Qadir Baksh - Baloch
  • 32,612
  • 68
  • 179
  • 322
  • 1
    have you even tried to google? ... http://www.codeproject.com/Articles/288150/Thread-Synchronization-with-Interlocked-Class –  Dec 10 '12 at 08:37
  • @AndreasNiedermair, I am aware about these constructs. I just wanted to ask If int is thread safe the why we need these constructs? – Imran Qadir Baksh - Baloch Dec 10 '12 at 08:42
  • 1
    Because you obviously do not know what thread safe means, you know. – TomTom Dec 10 '12 at 08:51
  • if you are aware of these constructs, why do you ask such questions? you are obviously not aware of the differences: int itself is threadsafe ... but read AND write (combined) is not ... (whereas read or write is atomic). –  Dec 10 '12 at 10:07

2 Answers2

1

Any one can tell me the reason for using these constructs.

it is not about thread safety of reading / writing. But about thread safety of the COMPLETE operation.

Increment is read, add 1, write. With interlocked that is guaranteed to happen in one "transaction." Same with compare/exchange.

if you do not write it with some sort of locking, then you may get interrupted BETWEEN the operations.

Read Inrecement Write

Every of the 3 steps is atomic, but not the combination. Someone else may have changed the value when you write back - interlocked ensures the WHOLE operation is atomic.

TomTom
  • 61,059
  • 10
  • 88
  • 148
  • So, we can say that int is not thread safe? But according to eric it is thread safe? see the link above – Imran Qadir Baksh - Baloch Dec 10 '12 at 08:45
  • @user960567 The quote in the link says `int` is _atomic_, not _thread safe_. – Rawling Dec 10 '12 at 08:46
  • @Rawling, what is the difference then? – Imran Qadir Baksh - Baloch Dec 10 '12 at 08:48
  • 2
    Atomic means in one operation - you can not "split" it. This is not thread safety (method). Plus this is not about the atomiticy of a VARIABLE, but the atomicity of MULTIPLE OPERATIONS ON A VARIABLE. Increment is 3 different operations. WIthout interlock, those are not atomic AS A WHOLE. – TomTom Dec 10 '12 at 08:50
  • OK, you are saying that writing int is atomic. So, why we need ComapreExchange. Just think about this, reading/writing int is atomic according to C# spec. Then it means writing(setting) a variable should be atomic. What is the benefits of this statement in C#? – Imran Qadir Baksh - Baloch Dec 10 '12 at 10:09
  • 1
    The fact that READ/WRITE is not atomic AS COMBINATION. And if you need to do a CompareExchange as a ATOMIC operation - then it is useless o know that the steps are atomic, if the combination is not. – TomTom Dec 10 '12 at 10:10
1

As mentioned already, you probably want to be googling this.

However, to answer the question of "why bother using InterlockedIncrement(&c.)?", while it is true that you can always perform a simple access of an int and it is guaranteed not to return anything half-written, you can not guarantee that a "read-and-modify" operation such as an increment is going to do what you expect.

InterlockedIncrement and its ilk, all guarantee that the operation will be performed atomically - so in the case of InterlockedIncrement itself, if two threads both call it on the same int, then the int is guaranteed to be incremented twice with the correct value being returned to the calling threads. However, doing a simple 'i++;' on two threads at the same time (for the same 'i') may result in an incorrect value being read.

This is because an increment such as 'i++' is broken down into at least two machine instructions: "read the value" and "increment the value" (or possibly worse: "read", "increment local value", "write"). If both threads do this at exactly the same time, then they may both read the value 0, but the incremented value could end up being 2.

Scott Earle
  • 660
  • 9
  • 21