Value types immune from thread racing because of this?

[Xyncgas]

I heard value types like int is going to get atomic operation when you add two together.

I understand if you modify a integer concurrently in two different thread it's not going to get corrupt bits instead each thread reads the original value then add a number then store the new value, now I am wondering if these operations are always going to be sequential meaning the thread that's adding something to the original value is always going to add it instead of reading the original value then having another one thread store whatever computed then it overwrites the computed result

Rumor : https://stackoverflow.com/questions/11745440/what-operations-are-atomic-in-c

[En3Tho]

https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md - I believe you should read this. It should clear most questions regarding memory operations in .Net runtime

[huoyaoyuan]

now I am wondering if these operations are always going to be sequential meaning the thread that's adding something to the original value is always going to add it instead of reading the original value then having another one thread store whatever computed then it overwrites the computed result

If two operations are atomic themselves (for assignment, not the whole read-compute-write operation), and their result can't co-exist (a memory address can't have two values on processor with strong consistency model), they must happen in some order.

[svick]

thread that's adding something to the original value is always going to add it instead of reading the original value then having another one thread store whatever computed then it overwrites the computed result

That is not guaranteed. In other words, this is not atomic: location++;, because it behaves the same as location = location + 1;. This is atomic: Interlocked.Increment(ref location);.

But thread-safety is a complicated topic. If you're not certain, the safer bet is to use locking instead of interlocked operations.

[Clockwork-Muse]

... It would be helpful to know what you're looking at there, but the answer there is "NO". If you have two threads racing, you should assume that the reads and writes will be interleaved, and you get results like your previous comment (unless you take special in one of a few special ways; just performing the operations is unsafe).

[Clockwork-Muse]

There's two different definitions of "atomic" being referenced here.

The first, and better-known definition, is "operation" atomicity, which is what @svick is referring to (and everybody else seems to be as well). This requires locks or Interlocked. The catch is that you need multiple operations to be atomic, and addition is one operation... and read and store are two additional operations. This is mostly constant across all versions and platforms.

The second, not as commonly known, is "storage" atomicity, which depends heavily on processor, most usually on bit-width. This is where, if you had multiple threads trying to store a value, you could get some bits from one thread and some bits from another, "tearing" the value. Historically, this primarily came when trying to work with longs (or doubles) - a 64-bit value - on 32-bit processors, because you needed two memory access to read/write the value. This is why Interlocked.Read(...) exists. Although 32-bit processors are still in use (mostly in ARM or other micros), the more usual thing to consider now is structs, which can be much larger than the current standard processor size of 64-bits...

[huoyaoyuan]

Are you talking about Interlocked.Increment?

[Xyncgas]

yes thanks

[Clockwork-Muse]

Increment only... increments. There's also Interlocked.Add if you need non-increment values. For anything more complicated, you either need a lock, or some fancier pattern (which depends too much on what you're actually doing).

Note that just because the Interlocked methods are safe, doesn't mean that your entire use of them will be safe....

[Xyncgas]

Don't worry I can implement a semaphore with atomic increments, I just add 1 to the counter every times acquire happens, add one to another counter when release happens, then check if release equals to acquire (if is threads are finished with whatever they are doing). If a maximum set to restrict how many entering shall happen, I can either yield async or return false or block to wait, I gotta be confident of the counter is correct that's all

[Clockwork-Muse]

then check if release equals to acquire

This is not (necessarily) threadsafe, because it's two separate reads/increments. The traditional way to do a semaphore is with one variable, and triggering off 0/non-zero. See for example oldnewthing (although that's C++, and some things are different).

That said, why are you writing a semaphore, when there's one in the base library?