If you could make any changes to D, what would they look like?
snarwin at gmail.com
Mon Oct 25 20:41:25 UTC 2021
On Monday, 25 October 2021 at 20:12:04 UTC, Ola Fosheim Grøstad
> On Monday, 25 October 2021 at 19:52:10 UTC, Paul Backus wrote:
>> It can be assumed not to cause a data race, which means that
>> an atomic operation on a `shared` variable is exactly as safe
>> as the corresponding non-atomic operation on a thread-local
> Of course it can't. Let take the simplest of the simple; a
> struct with a date with 3 fields_ day, month and year. Now, let
> us assume "2021-10-31". And then we add one day using atomics?
I agree that trying to do this with atomics will not give you the
right answer, but it is at least guaranteed not to cause
undefined behavior (excluding contract/assertion failures).
Safety does not imply correctness.
>>> *Thread-local memory locations* are accessible from only one
>>> thread at a time.
> That is way too weak to get the benefits that are desirable,
> meaning: a competitive edge over C++.
> I can create a template-wrapper in C++ too. So, as is, "shared"
> provides no advantage as far as I can tell.
The advantages are:
1. In C++, such a template wrapper would be opt-in. In D,
`shared` is opt-out.
2. `@safe` D code can assume that anything non-`shared` is
thread-local, because only `@system` or `@trusted` code can cast
to and from `shared`.
In other words, it makes code easier to reason about and
concurrency bugs easier to isolate.
You are probably correct that `shared` is not very useful for
enabling compiler optimizations relative to what is possible in
More information about the Digitalmars-d