If you could make any changes to D, what would they look like?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Mon Oct 25 20:12:04 UTC 2021
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? How?
If I declare something as shared as a type, then I expect some
solid means to protect it.
The current setup is too naive to be useful. It is no better than
a wrapper-template. It does not need to implemented in the type
system. It could have been implemented as a regular library.
This is not to say that the concept of "shared" is not useful. It
is the might-as-well-have-been-a-template-wrapper-approach that
> [The language spec] defines "thread local" as follows:
>> *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.
> And further clarifies that
>> A memory location can be temporarily transferred from shared
>> to local if synchronization is used to prevent any other
>> threads from accessing the memory location during the
> Of course, the compiler will not stop you from writing
> incorrect casts in `@system` code, but that's not an issue
> unique to `shared`.
I don't see how this can be guaranteed. The compiler _needs_ to
know where the line in the sand is drawn so that is isn't limited
by the potentially performance-limiting sequencing points that
C++ has to deal with.
For instance: what are the lifetimes for cached computations when
you don't know if another thread will obtain access to what you
received as a "nonshared object"?
Also, in order to get solid GC performance the compiler needs to
know whether the memory is owned by the thread or is foreign to
"shared" has to be more than a shell in order to enable more
More information about the Digitalmars-d