On Wed, Mar 20, 2019 at 11:20 AM Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 20 March 2019 at 13:25:01 UTC, Stefan Koch wrote:
> > In it's current form the `shared` qualifier is not improving
> > the thread-safety
> > of D code.
>
> It does, proof: https://issues.dlang.org/show_bug.cgi?id=6585

That is most certainly not a bug, that's absolutely 100% correct behaviour.
It's absolutely not okay to pass a pointer to shared data to memcpy!
It needs some external synchronisation, and then cast shared away when
you know you have a thread-local lock on it.

> > Being conservative and disallowing all access is by far the
> > most sensible handling
> > if safety is a concern.
>
> Added noise and cognitive load on programmer causes more bugs, not more safety. shared is already restrictive enough to handle, making it more restrictive will only make people give up on it more often.

So, just to be clear, you favour shared being broken and meaningless
to actually meaning something and being useful?
I don't have the energy to repeat the last uber-thread on the issue;
you'll find the full discussion in the forum history.

On Wednesday, 20 March 2019 at 20:15:23 UTC, Manu wrote:
> So, just to be clear, you favour shared being broken and meaningless
> to actually meaning something and being useful?

Its meaning is to provide guarantee that thread-local data doesn't have threading issues and I posted the proof of its usefulness.

On Thursday, 21 March 2019 at 19:03:23 UTC, Kagamin wrote:
> On Wednesday, 20 March 2019 at 20:15:23 UTC, Manu wrote:
>> So, just to be clear, you favour shared being broken and meaningless
>> to actually meaning something and being useful?
>
> Its meaning is to provide guarantee that thread-local data doesn't have threading issues and I posted the proof of its usefulness.

If the data is thread local, then it is already guaranteed to have no conflict with other threads. Hence it being "thread local", only the local thread can access the data. There's no need for a "shared" qualifier in this regard.

On Thu, Mar 21, 2019 at 12:05 PM Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 20 March 2019 at 20:15:23 UTC, Manu wrote:
> > So, just to be clear, you favour shared being broken and
> > meaningless
> > to actually meaning something and being useful?
>
> Its meaning is to provide guarantee that thread-local data doesn't have threading issues and I posted the proof of its usefulness.

But that's now what `shared` does... it allows (guarantees even) many
threads mutate the same data at random with no protections.
By inhibiting read/write access, you force the user to obtain a lock
(or other synchronisation method) in order to access the shared data.
Without that, the path of least resistance is to just access the data,
and that's a race 100% of the time, by definition (because it's
`shared`).

On Thursday, 21 March 2019 at 19:50:31 UTC, Rubn wrote:
> If the data is thread local, then it is already guaranteed to have no conflict with other threads. Hence it being "thread local", only the local thread can access the data. There's no need for a "shared" qualifier in this regard.

In case of D the claim doesn't hang in a vacuum, but is supported by the type system.

On Thursday, 21 March 2019 at 20:50:09 UTC, Manu wrote:
> But that's now what `shared` does... it allows (guarantees even) many
> threads mutate the same data at random with no protections.
> By inhibiting read/write access, you force the user to obtain a lock
> (or other synchronisation method) in order to access the shared data.
> Without that, the path of least resistance is to just access the data,
> and that's a race 100% of the time, by definition (because it's
> `shared`).

Some memory accesses are thread safe, then synchronization is not needed.

On Monday, 25 March 2019 at 08:37:42 UTC, Kagamin wrote:
> On Thursday, 21 March 2019 at 20:50:09 UTC, Manu wrote:
>> But that's now what `shared` does... it allows (guarantees even) many
>> threads mutate the same data at random with no protections.
>> By inhibiting read/write access, you force the user to obtain a lock
>> (or other synchronisation method) in order to access the shared data.
>> Without that, the path of least resistance is to just access the data,
>> and that's a race 100% of the time, by definition (because it's
>> `shared`).
>
> Some memory accesses are thread safe, then synchronization is not needed.

So what you are saying is that shared can thread-safe;
For access where synchronization is not needed.
In those cases it technically does not matter if the data is shared or not.
Let's talk about the case now where data is actually shared between threads,
How can I distinguish in the type-system if I get a pointer which others may, write to at the same time?

Cheers,
Stefan

On Monday, 25 March 2019 at 08:36:42 UTC, Kagamin wrote:
> On Thursday, 21 March 2019 at 19:50:31 UTC, Rubn wrote:
>> If the data is thread local, then it is already guaranteed to have no conflict with other threads. Hence it being "thread local", only the local thread can access the data. There's no need for a "shared" qualifier in this regard.
>
> In case of D the claim doesn't hang in a vacuum, but is supported by the type system.

You don't use the type system with thread local data. Using shared, actually creates global data, not thread local data.

I'll ask this now since it seems you are talking mostly gibberish. Do you even know what thread local data is ?

On Monday, 25 March 2019 at 10:39:06 UTC, Stefan Koch wrote:
> How can I distinguish in the type-system if I get a pointer which others may, write to at the same time?

Qualified as shared, like anything that's not thread local.

On Monday, 25 March 2019 at 21:04:37 UTC, Rubn wrote:
> You don't use the type system with thread local data. Using shared, actually creates global data, not thread local data.

Unqualified types are specified to be thread local, so thread local data is definitely expressed in the type system.