What's the intrinsic of interlocked subtract if there is add

[devc1]

What's the intrinsic of atomic subtract if there is _interlockedadd

[thewrongchristian]

What's the intrinsic of atomic subtract if there is _interlockedadd

If you add a negative number, that will be the same as subtraction:

Code: Select all

_InterlockedAdd(counter, -valueToSubtract);

[devc1]

What about unsigned values ?

Probably 8 + (-1) which is 8 + 0xFFFFFFFFFFFFFFFF will lead to 7 ?? or an overflow ?

[Minoto]

What about unsigned values ?

Probably 8 + (-1) which is 8 + 0xFFFFFFFFFFFFFFFF will lead to 7 ?? or an overflow ?

What happened when you wrote the code and ran it?

[davmac314]

What happened when you wrote the code and ran it?

Signed integer overflow normally has undefined behaviour in C. The only documentation I've seen for InterlockedAdd doesn't say that there's any exception for it in regards to this, so I would strongly suggest not using any observed behaviour as a reliable indicator of general behaviour.

Edit: in general an unsigned integer value can be safely converted to a signed integer value of the same size (the result is implementation-defined in C99; all common compilers for common architectures that I know of will just reinterpret the bitwise value as a signed value, effectively wrapping since the representation is 2's complement). So, for this particular example it should be perfectly fine to use unsigned values to effectively subtract some amount from some integer, so long as the result when interpreted as an operation on signed integers doesn't overflow. Specifically:

Probably 8 + (-1) which is 8 + 0xFFFFFFFFFFFFFFFF will lead to 7 ?? or an overflow ?

The -1 will be treated as a signed value because _InterlockedAdd takes signed arguments, i.e. -1u becomes -1 (again: subject to implementation-defined behaviour). Hence there is no overflow for this example (assuming the usual implementation-defined behaviour).

However, my point stands: if you believe that an operation may involve overflow, do not attempt to determine the behaviour by observing it. If the behaviour is undefined, it will not necessarily behave consistently.

[Octocontrabass]

If the type promotion rules result in an unsigned type, overflow wraps around according to twos-complement arithmetic. If they result in a signed type, overflow results in undefined behavior. You need to be pretty familiar with basic arithmetic in your chosen programming language before you try to write an operating system in it.

[Minoto]

However, my point stands: if you believe that an operation may involve overflow, do not attempt to determine the behaviour by observing it. If the behaviour is undefined, it will not necessarily behave consistently.

Point taken. My intention was to encourage trying something to find out for oneself, but that's not necessarily always the best approach.

[devc1]

Looking at the intrinsic function, it does say that the value is signed. There is no 64 Bit address space yet so I won't need an unsigned integer for most of the time.
But the tip from thewrongchristian works perfectly for me, thanks.