www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1024---Shared Atomics---Final Review

reply Mike Parker <aldacron gmail.com> writes:
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.
Dec 08 2019
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:

 https://github.com/dlang/DIPs/blob/78a5bc098fa00c44f11d1819919eb78b8d263254/DIPs/DIP1024.md


Do the limitations apply to inline assembly?

While working on a Phobos PR [1] I tried changing a __gshared 
variable declaration [2] to shared to make the function  safe. 
The variable is only written to with a mov instruction [3] for 
timing reasons, and never read.

The DIP doesn't specify what happens here, though I'd argue that 
assembly blocks are inherently "no type system, you know what 
you're doing" so it can be allowed.

If it is going to be forbidden, then I need to know how to cast 
away shared from a global variable in inline assembly.

[1] https://github.com/dlang/phobos/pull/7296
[2] 
https://github.com/dlang/phobos/blob/a24888e533adfe8d141eb598be22a50df5e26a66/std/internal/math/biguintx86.d#L759
[3] 
https://github.com/dlang/phobos/blob/a24888e533adfe8d141eb598be22a50df5e26a66/std/internal/math/biguintx86.d#L692
Dec 08 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/8/2019 9:42 AM, Dennis wrote:

 Do the limitations apply to inline assembly?


No. Inline assembly is always unrestricted.
Dec 08 2019
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Sunday, 8 December 2019 at 16:25:21 UTC, Mike Parker wrote:

 https://github.com/dlang/DIPs/blob/78a5bc098fa00c44f11d1819919eb78b8d263254/DIPs/DIP1024.md



 Alternatives. Provide limited support for locked operations 
 with operators where the CPU supports it. C++ provides such. 
 This is controversial, as some believe it encourages incorrect 
 coding practices.


This could use a reference, I couldn't find anything about this 
after a quick search.
Dec 08 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/8/2019 9:46 AM, Dennis wrote:

 Alternatives. Provide limited support for locked operations with operators 
 where the CPU supports it. C++ provides such. This is controversial, as some 
 believe it encourages incorrect coding practices.


 
 This could use a reference, I couldn't find anything about this after a quick 
 search.


Verbal discussion with Herb Sutter. Not something I can cite.
Dec 08 2019
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/8/19 11:25 AM, 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/78a5bc098fa00c44f11d1819919eb78b8d26
254/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.


Nothing to add. Looks exactly correct. I look forward to this being 
implemented.

-Steve
Dec 08 2019
parent Manu <turkeyman gmail.com> writes:
On Mon, Dec 9, 2019 at 3:55 AM Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/8/19 11:25 AM, 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.


 Nothing to add. Looks exactly correct. I look forward to this being
 implemented.

 -Steve


This has been such a long time coming!
Dec 08 2019
prev sibling next sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
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.
Dec 10 2019
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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/78a5bc098fa00c44f11d1819919eb78b8d26
254/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
Dec 10 2019
prev sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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);
Dec 10 2019
prev sibling next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
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.
Dec 10 2019
next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
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
Dec 10 2019
next sibling parent reply IGotD- <nise nise.com> writes:
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.
Dec 10 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Dec 10 2019
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 11 December 2019 at 04:45:41 UTC, rikki cattermole 
wrote:

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


Not the only one. Here's an incomplete list of things that also 
work:
https://github.com/dlang/druntime/tree/master/test/betterc/src
Dec 11 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 11 2019
parent reply Manu <turkeyman gmail.com> writes:
On Wed, Dec 11, 2019 at 7:30 PM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 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.


core.stdc, core.stdcpp, core.atomic should be all inline (or externs
to the C lib) and absolutely not require linking any d-libs.
Sadly, we don't have an inline qualifier that works right; the only
hack we have is to make should-be-inline functions a template with no
template args, which is a lame hack that frustrates some forms of meta
:/
Dec 11 2019
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Wednesday, 11 December 2019 at 09:47:12 UTC, Manu wrote:

 On Wed, Dec 11, 2019 at 7:30 PM Walter Bright via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 [...]


 core.stdc, core.stdcpp, core.atomic should be all inline (or 
 externs
 to the C lib) and absolutely not require linking any d-libs.
 Sadly, we don't have an inline qualifier that works right; the 
 only
 hack we have is to make should-be-inline functions a template 
 with no
 template args, which is a lame hack that frustrates some forms 
 of meta
 :/


This is a bit risky. Consider that the function in core.atomic 
might use other non-template functions from druntime which will 
cause a link time failure.
Dec 11 2019
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 11 December 2019 at 11:23:12 UTC, RazvanN wrote:

 On Wednesday, 11 December 2019 at 09:47:12 UTC, Manu wrote:

 On Wed, Dec 11, 2019 at 7:30 PM Walter Bright via 
 Digitalmars-d <digitalmars-d puremagic.com> wrote:

 [...]


 core.stdc, core.stdcpp, core.atomic should be all inline (or 
 externs
 to the C lib) and absolutely not require linking any d-libs.
 Sadly, we don't have an inline qualifier that works right; the 
 only
 hack we have is to make should-be-inline functions a template 
 with no
 template args, which is a lame hack that frustrates some forms 
 of meta
 :/


 This is a bit risky. Consider that the function in core.atomic 
 might use other non-template functions from druntime which will 
 cause a link time failure.


No it's not risky as there are only two sensible ways of 
implementing of core.atomic:
1. Inline assembly (per each supported target arch)
2. GCC or LLVM intrinsics/builtins (I think GCC's libatomic would 
be categorized as builtin)

DMD uses 1. whereas GDC and LDC use 2.

As such, core.atomic doesn't have any link-time dependencies and 
so it's 100% -betterC compatible. If you can check the source 
code you will see that there are  betterC unit tests that ensure 
that core.atomic works in -betterC mode:

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L889

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L968

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L1008

https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L1066

As long as we have those tests, there's no risk in making 
core.atomic incompatible with -betterC.
Dec 11 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L528

;)
Dec 11 2019
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 11 December 2019 at 13:09:48 UTC, rikki cattermole 
wrote:

 https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L528

 ;)


That's trivially fixable ;)
Dec 11 2019
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 11 December 2019 at 13:13:39 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Wednesday, 11 December 2019 at 13:09:48 UTC, rikki 
 cattermole wrote:

 https://github.com/dlang/druntime/blob/7a6d30d457fe52d56d3b8241ad10cc7a4a049ed1/src/core/atomic.d#L528

 ;)


 That's trivially fixable ;)


Also unrelated to the discussion about `shared`.
Dec 11 2019
prev sibling parent Manu <turkeyman gmail.com> writes:
On Wed, Dec 11, 2019 at 9:25 PM RazvanN via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 11 December 2019 at 09:47:12 UTC, Manu wrote:

 On Wed, Dec 11, 2019 at 7:30 PM Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 [...]


 core.stdc, core.stdcpp, core.atomic should be all inline (or
 externs
 to the C lib) and absolutely not require linking any d-libs.
 Sadly, we don't have an inline qualifier that works right; the
 only
 hack we have is to make should-be-inline functions a template
 with no
 template args, which is a lame hack that frustrates some forms
 of meta
 :/


 This is a bit risky. Consider that the function in core.atomic
 might use other non-template functions from druntime which will
 cause a link time failure.


They don't. If they did, those functions should be inline too.
Dec 13 2019
prev sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Tuesday, 10 December 2019 at 15:26:02 UTC, Simen Kjærås wrote:

 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.


If you think from an implementation point of view, the compiler 
will most likely search for specific functions that can be called 
on shared variables (a finite list that contains only the 
functions defined in druntime). The only way you can override 
that is to define functions that have exactly the same name as 
the ones in druntime, but that is risky because the compiler does 
not have any way of verifying that you are actually synchronizing 
the access.



 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.


Yes, the function in core atomic are templates, but if there are 
internal calls to non-templated functions you will end up with a 
link error.


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

 --
   Simen
Dec 11 2019
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 11 December 2019 at 11:21:22 UTC, RazvanN wrote:

 If you think from an implementation point of view, the compiler 
 will most likely search for specific functions that can be 
 called on shared variables (a finite list that contains only 
 the functions defined in druntime). The only way you can 
 override that is to define functions that have exactly the same 
 name as the ones in druntime, but that is risky because the 
 compiler does not have any way of verifying that you are 
 actually synchronizing the access.


That's not true. The compiler has no knowledge of the existence 
of core.atomic (modulo suggesting the user to use it in some 
error messages). You can pass shared data to any function 
parameter that is also marked as shared. As such, `shared` works 
like any other type qualifier.

 Yes, the function in core atomic are templates, but if there 
 are internal calls to non-templated functions you will end up 
 with a link error.


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

 --
   Simen




As mentioned previously, atomic ops on `shared` data work 100% no 
matter if you're compiling with -betterC or not. In the worst 
case, if one would not even want to import core.atomic (I don't 
see a reason for that), they can still:

1. Copy and paste the parts of core.atomic that they need in 
their code base. The names of the function doesn't need to match 
at all.

2. Use other libraries (e.g. from C and C++) that implement 
atomic operations. To prevent unnecessary casting from `shared`, 
the `extern (C)` / `extern (C++)` signatures should use the 
`shared` type qualifier for parameters.

3. Implement the atomic ops that they need themselves.
Dec 11 2019
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Wednesday, 11 December 2019 at 13:12:45 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Wednesday, 11 December 2019 at 11:21:22 UTC, RazvanN wrote:

 If you think from an implementation point of view, the 
 compiler will most likely search for specific functions that 
 can be called on shared variables (a finite list that contains 
 only the functions defined in druntime). The only way you can 
 override that is to define functions that have exactly the 
 same name as the ones in druntime, but that is risky because 
 the compiler does not have any way of verifying that you are 
 actually synchronizing the access.


 That's not true. The compiler has no knowledge of the existence 
 of core.atomic (modulo suggesting the user to use it in some 
 error messages). You can pass shared data to any function 
 parameter that is also marked as shared. As such, `shared` 
 works like any other type qualifier.




I see, so basically the compiler simply checks that accesses to 
shared data are made by calling functions that receive shared 
data. The leafs will modify the data via inline assembly or 
external functions.


 Yes, the function in core atomic are templates, but if there 
 are internal calls to non-templated functions you will end up 
 with a link error.


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

 --
   Simen




 As mentioned previously, atomic ops on `shared` data work 100% 
 no matter if you're compiling with -betterC or not. In the 
 worst case, if one would not even want to import core.atomic (I 
 don't see a reason for that), they can still:

 1. Copy and paste the parts of core.atomic that they need in 
 their code base. The names of the function doesn't need to 
 match at all.

 2. Use other libraries (e.g. from C and C++) that implement 
 atomic operations. To prevent unnecessary casting from 
 `shared`, the `extern (C)` / `extern (C++)` signatures should 
 use the `shared` type qualifier for parameters.

 3. Implement the atomic ops that they need themselves.





 Dec 11 2019



  parent  Petar Kirov [ZombineDev] <petar.p.kirov gmail.com>  writes:


On Wednesday, 11 December 2019 at 13:28:36 UTC, RazvanN wrote:

 I see, so basically the compiler simply checks that accesses to 
 shared data are made by calling functions that receive shared 
 data. The leafs will modify the data via inline assembly or 
 external functions.


Correct.



 Dec 11 2019



prev sibling next sibling parent  Petar Kirov [ZombineDev] <petar.p.kirov gmail.com>  writes:


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.



 Dec 10 2019



prev sibling  parent  Manu <turkeyman gmail.com>  writes:


On Tue, Dec 10, 2019 at 10:21 PM RazvanN via Digitalmars-d
<digitalmars-d puremagic.com> 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.


How so? I don't see any reason that's true,



 Dec 11 2019



prev sibling next sibling parent reply RazvanN <razvan.nitu1305 gmail.com>  writes:


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?



 Dec 10 2019



 next sibling parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


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



 Dec 10 2019



prev sibling next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com>  writes:


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



 Dec 10 2019



  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


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



 Dec 10 2019



prev sibling next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/10/2019 4:18 AM, RazvanN wrote:

 If you have a const shared variable, do you still need locks to read it?


Yes, because const is a read only view. Other views may mutate it.

Only immutables don't need locks, because then nobody can mutate it.



 Dec 11 2019



prev sibling  parent  Manu <turkeyman gmail.com>  writes:


On Tue, Dec 10, 2019 at 10:21 PM RazvanN via Digitalmars-d
<digitalmars-d puremagic.com> 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?


Absolutely.



 Dec 11 2019



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Some hashtags:

#dip1024
#sharedAtomics
#sequentialConsistency
#dataRace



 Dec 16 2019