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