• Illuminati (6/6) Aug 28 2016 What are the D equivalents to these types of functions?
• Lodovico Giaretta (5/11) Aug 28 2016 I'm not an expert in this field (so probably I'm missing
• Jack Applegame (6/18) Aug 28 2016 Exactly!
• Illuminati (7/19) Aug 28 2016 The interlocked functions generate memory barriers, does atomicOp
• David Nadlinger (7/10) Aug 28 2016 It isn't. In fact, using volatile to achieve thread
• Lodovico Giaretta (12/17) Aug 28 2016 I'm under the impression that atomicOp does not generate memory

Illuminati <Joe Masons.com> writes:

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.

Lodovico Giaretta <lodovico giaretart.net> writes:

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.

Jack Applegame <japplegame gmail.com> writes:

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

Illuminati <Joe Masons.com> writes:

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.

David Nadlinger <code klickverbot.at> writes:

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

Lodovico Giaretta <lodovico giaretart.net> writes:

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.