On 12/10/19 6:30 AM, Martin Tschierschke wrote:
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>> DIP 1024, "Shared Atomics", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.
>>
>> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> The current revision of the DIP for this review is located here:
>>
>> https://github.com/dlang/DIPs/blob/78a5bc098fa00c44f11d1819919eb78b8d263254/DIPs/DIP1024.md 
>>
>>
>> In it, you'll find a link to and summary of the previous review rounds. This round of review will continue until 11:59 pm ET on December 23 unless I call it off before then.
>>
>> Thanks in advance for your participation.
> 
> Can somebody please give or point to simple examples on howto use core.atomic:
> 
> shared int x;        // ok, initialization to 0
> ++x;                 // error, read and write of shared x
> 
> Looking into https://dlang.org/phobos/core_atomic.html was not so helpful for me.
> 

atomicOp!"+="(x, 1);

-Steve

On 12/10/19 7:18 AM, RazvanN wrote:
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
> 
> If you have a const shared variable, do you still need locks to read it?
> 
> 

To be consistent, I'd say you'd need at least a cast. Do you need a lock? I don't think so for something that has a const storage class.

Note that the DIP does not address whether you need a lock for anything, it just says you can't use it in it's "shared" form, you need to cast away shared or use a function that does this internally.

-Steve

On Tuesday, 10 December 2019 at 12:18:39 UTC, RazvanN wrote:
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>
> If you have a const shared variable, do you still need locks to read it?

You'll need to cast away shared. You can of course do that without locks, but you probably shouldn't.

The reason is that, even though const ensures *you* cannot modify it, others may, and you risk reading inconsistent data.

--
  Simen

On Tuesday, 10 December 2019 at 11:30:36 UTC, Martin Tschierschke wrote:
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>> [...]
>
> Can somebody please give or point to simple examples on howto use core.atomic:
>
> shared int x;        // ok, initialization to 0
> ++x;                 // error, read and write of shared x
>
> Looking into https://dlang.org/phobos/core_atomic.html was not so helpful for me.

shared int x, y;
x.atomicStore(41);
x.atomicOp!`+=`(1);
y.atomicStore = x.atomicLoad;
bool res = (&y).cas(42, 123);
assert(res);
assert(y.atomicLoad == 123);

On Tuesday, 10 December 2019 at 12:16:29 UTC, RazvanN wrote:
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>
> I think that it should be stated somewhere that the DIP makes shared unusable in betterC code.

There's nothing stopping you from implementing your own primitives for manipulating shared data in betterC - core.atomic is only mentioned because it's the standard library way to do it.

It seems unlikely that core.atomic uses the features that betterC disables, and where it does a betterC version should be relatively easy to write. I expect this will be on dub within a week of this being implemented, and if it isn't you can just copy the parts you need from core.atomic.

In short, using shared in betterC may be harder, but it's far from unusable.

--
  Simen

On Tuesday, 10 December 2019 at 12:16:29 UTC, RazvanN wrote:
> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>
> I think that it should be stated somewhere that the DIP makes shared unusable in betterC code.

-betterC restricts only features that require druntime or phobos to be linked. If one is using templates and those templates don't use such features (but can call other template functions) it's not a problem since the templates would be instantiated in the user's object files and the linker won't try to find them in the druntime/phobos libraries.

On Tuesday, 10 December 2019 at 15:26:02 UTC, Simen Kjærås wrote:
>
> There's nothing stopping you from implementing your own primitives for manipulating shared data in betterC - core.atomic is only mentioned because it's the standard library way to do it.
>
> --
>   Simen

This is a problem with that OS dependent libraries aren't separated from OS independent libraries. In the future the atomic library should be in an OS independent part of the core library while those that depends on an underlying OS should be in their own. In all we need a finer granularity of the standard library depending on what the library depends on. Future DIP needed for this.

On 12/10/19 10:13 AM, Simen Kjærås wrote:
> On Tuesday, 10 December 2019 at 12:18:39 UTC, RazvanN wrote:
>> On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:
>>
>> If you have a const shared variable, do you still need locks to read it?
> 
> You'll need to cast away shared. You can of course do that without locks, but you probably shouldn't.
> 
> The reason is that, even though const ensures *you* cannot modify it, others may, and you risk reading inconsistent data.

This only makes sense for const references. A const variable is const.

Like a const int. Nobody can modify it, because the storage class is const, it's impossible (without casting away const) to get a mutable reference.

So I think it's OK not to lock, but yes, you should have to cast away shared.

-Steve

On 11/12/2019 4:55 AM, IGotD- wrote:
> On Tuesday, 10 December 2019 at 15:26:02 UTC, Simen Kjærås wrote:
>>
>> There's nothing stopping you from implementing your own primitives for manipulating shared data in betterC - core.atomic is only mentioned because it's the standard library way to do it.
>>
>> -- 
>>   Simen
> 
> This is a problem with that OS dependent libraries aren't separated from OS independent libraries. In the future the atomic library should be in an OS independent part of the core library while those that depends on an underlying OS should be in their own. In all we need a finer granularity of the standard library depending on what the library depends on. Future DIP needed for this.

As far as I know core.atomic is the only module in druntime that will operate without druntime.

(There is a few random functions that are not templated, but that I'm pretty sure is just an oversight).

I'm not including bindings in this description as it doesn't include any logic.

On 12/10/2019 7:55 AM, IGotD- wrote:
> This is a problem with that OS dependent libraries aren't separated from OS independent libraries. In the future the atomic library should be in an OS independent part of the core library while those that depends on an underlying OS should be in their own. In all we need a finer granularity of the standard library depending on what the library depends on. Future DIP needed for this.


The idea of betterC is to not rely on ANY D libraries. As soon as we say "to use betterC you'll need to download and install these D libraries" it's dead in the water.

If you use shared language operators in betterC you're just as hosed as using them in D. You'll need library code to do it, and you can use any C library that offers atomic ops to do it.