Thread overview
InterlockedIncrement, InterlockedCompareExchange, etc
Aug 28, 2016
Illuminati
Aug 28, 2016
Lodovico Giaretta
Aug 28, 2016
Jack Applegame
Aug 28, 2016
Illuminati
Aug 28, 2016
David Nadlinger
Aug 28, 2016
Lodovico Giaretta
August 28, 2016
What are the D equivalents to these types of functions?

I do not see anything in core.atomic that can accomplish this. I have tried to include core.sys.windows.winbase but still get linker errors(I've also directly tried importing kernel32 using various methods and still nothing). Regardless, would be nicer to have a more portable solution.


August 28, 2016
On Sunday, 28 August 2016 at 19:53:51 UTC, Illuminati wrote:
> What are the D equivalents to these types of functions?
>
> I do not see anything in core.atomic that can accomplish this. I have tried to include core.sys.windows.winbase but still get linker errors(I've also directly tried importing kernel32 using various methods and still nothing). Regardless, would be nicer to have a more portable solution.

I'm not an expert in this field (so probably I'm missing something), but I would think that InterlockedIncrement could be done with atomicOp!"+"(val, 1) and InterlockedCompareExchange with cas.
August 28, 2016
On Sunday, 28 August 2016 at 20:38:30 UTC, Lodovico Giaretta wrote:
> On Sunday, 28 August 2016 at 19:53:51 UTC, Illuminati wrote:
>> What are the D equivalents to these types of functions?
>>
>> I do not see anything in core.atomic that can accomplish this. I have tried to include core.sys.windows.winbase but still get linker errors(I've also directly tried importing kernel32 using various methods and still nothing). Regardless, would be nicer to have a more portable solution.
>
> I'm not an expert in this field (so probably I'm missing something), but I would think that InterlockedIncrement could be done with atomicOp!"+"(val, 1) and InterlockedCompareExchange with cas.
Exactly!
InterlockedIncrement - atomicOp!"+="(val, 1) or val.atomicOp!"+="(1)
InterlockedCompareExchange - cas
August 28, 2016
On Sunday, 28 August 2016 at 20:38:30 UTC, Lodovico Giaretta wrote:
> On Sunday, 28 August 2016 at 19:53:51 UTC, Illuminati wrote:
>> What are the D equivalents to these types of functions?
>>
>> I do not see anything in core.atomic that can accomplish this. I have tried to include core.sys.windows.winbase but still get linker errors(I've also directly tried importing kernel32 using various methods and still nothing). Regardless, would be nicer to have a more portable solution.
>
> I'm not an expert in this field (so probably I'm missing something), but I would think that InterlockedIncrement could be done with atomicOp!"+"(val, 1) and InterlockedCompareExchange with cas.

The interlocked functions generate memory barriers, does atomicOp do that?

Also D doesn't seem to have a volitile keyword anymore which is required to prevent the compiler from prematurely optimizing critical code.
August 28, 2016
On Sunday, 28 August 2016 at 21:52:48 UTC, Illuminati wrote:
> Also D doesn't seem to have a volitile keyword anymore which is required to prevent the compiler from prematurely optimizing critical code.

It isn't. In fact, using volatile to achieve thread synchronisation (seeing as this is what the original post was about) in C is almost always wrong.

Depending on the use case, {atomic, volatile}{Load, Store}() should fulfil your needs.

 — David
August 28, 2016
On Sunday, 28 August 2016 at 21:52:48 UTC, Illuminati wrote:
> The interlocked functions generate memory barriers, does atomicOp do that?
>
> Also D doesn't seem to have a volitile keyword anymore which is required to prevent the compiler from prematurely optimizing critical code.

I'm under the impression that atomicOp does not generate memory barriers. In fact, in its implementation, it uses atomicLoad with relaxed memory ordering.

There is however a function in core.atomic to generate a full memory barrier, if you need it.

By the way, can I ask you why you need this? Is it for low-level data sharing or for hardware access? If it is for low-level data sharing, then you probably don't need volatile, as shared should be enough. If it is for hardware access, the situation is more complex, but I'm sure I've seen some threads about how to implement Volatile!T in a few lines of code recently.