On Friday, 4 October 2019 at 10:12:45 UTC, Kagamin wrote:
> On Thursday, 3 October 2019 at 12:14:30 UTC, Stefan Koch wrote:
>> A coworker of mine (Don Clugston) came up with this analogy.
>> Multi-threading is a bit like radiating material, you put it in a safe-box, and put a warning sticker on it, such that only professionals may open it.
>> And even the professional would not want to be around the material for very long and certainly would want to be warned before he accesses the material.
>> Therefore the material should be in it's designated box sealed away fore the majority of the time.
>
> Sounds like that coworker wants @safe code. The DIP is justified for safe code, but not for system code. Also the DIP provides memory safety, not thread safety.

The reason why you want shared access to be forbidden by default is to see where synchronization is required and force you to think about it.
In all your code not just safe code.

In my opinion, if a DIP is so confusingly written that most people don't understand what it is proposing, the review should be stopped, the DIP should be rewritten and then a new review should be started. Otherwise the review thread just gets full of irrelevant comments that are based on misunderstandings, and therefore becomes hard to follow.

This is the case for this DIP.

This comment by Walter made it more clear, where the inconsistencies originate from:

On Friday, 4 October 2019 at 03:35:45 UTC, Walter Bright wrote:
> Yes. The trouble stems from the DIP being originally written to apply shared semantics to operators. This was changed to be function only, and some vestiges of the original remain. Hence the confusion.

It is not, however, an excuse not to fix the text before restarting the review.

***

When it comes to the actual content of this DIP, it should describe clearly both
1) what the current behavior is before this DIP
2) what the behavior would be after this DIP

(Currently 1 is either not addressed at all, or described very implicitly. And 1 is described inconsistently and not very clearly.)

On Friday, 4 October 2019 at 12:22:16 UTC, Stefan Koch wrote:
> The reason why you want shared access to be forbidden by default is to see where synchronization is required and force you to think about it.
> In all your code not just safe code.

That's achieved by writing safe code, so the failure requires transition to trusted code, where there's type system and lack of conversion between shared and unshared data. Adding churn indefinitely isn't very practical, it increases cognitive load on programmer and diverts resources that can be spent on thinking about synchronization. Also the idea ignores the problem that people deem it difficult to work with shared data, adding more churn only worsens that problem, which is traded for an alleged solution to a hypothetical problem.

On Mon, Oct 7, 2019 at 1:05 AM Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Friday, 4 October 2019 at 12:22:16 UTC, Stefan Koch wrote:
> > The reason why you want shared access to be forbidden by
> > default is to see where synchronization is required and force
> > you to think about it.
> > In all your code not just safe code.
>
> That's achieved by writing safe code, so the failure requires transition to trusted code, where there's type system and lack of conversion between shared and unshared data. Adding churn indefinitely isn't very practical, it increases cognitive load on programmer and diverts resources that can be spent on thinking about synchronization. Also the idea ignores the problem that people deem it difficult to work with shared data, adding more churn only worsens that problem, which is traded for an alleged solution to a hypothetical problem.

This made exactly no sense to me. I don't know what you're saying here. That said, based on your past posts, I think I need to assure you that it is **NEVER** acceptable to freely read/write to shared data, and that doesn't only apply to @safe code.

I wish Walter would update this DIP, but based on his comments, I think it's going the right way...?

On Wednesday, 9 October 2019 at 18:25:36 UTC, Manu wrote:
> This made exactly no sense to me. I don't know what you're saying here. That said, based on your past posts, I think I need to assure you that it is **NEVER** acceptable to freely read/write to shared data, and that doesn't only apply to @safe code.

Maybe set up a list of what problems and opportunities "shared" is supposed to deal with? What will it solve, and just as importantly, list explicitly which issues it won't deal with.

As far as I can tell, one could get better optimization if one could assume that certain memory areas are not accessed by other threads and avoid C++-ish sequencing points even in code that use concurrency-primitives. That seems to be out of scope?

If C++ is supposed to interface with D, then the spec ought to present an argument for how D's memory model is compatible with C++, which may be summed up as (quoting cppreference.com):

«Any thread can potentially access any object in the program (objects with automatic and thread-local storage duration may still be accessed by another thread through a pointer or by reference).

Different threads of execution are always allowed to access (read and modify) different memory locations concurrently, with no interference and no synchronization requirements.»

On Thursday, 10 October 2019 at 07:03:26 UTC, Ola Fosheim Grøstad wrote:
> As far as I can tell, one could get better optimization if one could assume that certain memory areas are not accessed by other threads and avoid C++-ish sequencing points even in code that use concurrency-primitives. That seems to be out of scope?

Or to be blunt, if "shared" has no effect on the IR then it ought to be removed from the language and replaced with mechanisms that makes it possible to implement the "shared" marker functionality as a template wrapper.

On 10/9/2019 11:25 AM, Manu wrote:
> I wish Walter would update this DIP, but based on his comments, I
> think it's going the right way...?

I'll update it to clear up the ambiguity in it after this review cycle is over.

It'll be clear that reads and writes to shared data will not be allowed directly, you'll have to go through a function.

On 10/2/2019 3:42 AM, Nicholas Wilson wrote:
> On Wednesday, 2 October 2019 at 08:55:59 UTC, Kagamin wrote:
>> Access to shared memory should be disallowed only for safe code, but not for system code.
> 
> That definition doesn't play nice with safety inference i.e. templates.
> 
> It should be that shared memory access is disabled in all contexts,
> which must be worked around with casts,
> which makes the function @system,
> which must then be encapsulated with a @trusted interface in order to use in @safe code.

Sounds right.

On Friday, October 11, 2019 10:58:29 PM MDT Walter Bright via Digitalmars-d wrote:
> On 10/2/2019 3:42 AM, Nicholas Wilson wrote:
> > On Wednesday, 2 October 2019 at 08:55:59 UTC, Kagamin wrote:
> >> Access to shared memory should be disallowed only for safe code, but not for system code.
> >
> > That definition doesn't play nice with safety inference i.e. templates.
> >
> > It should be that shared memory access is disabled in all contexts,
> > which must be worked around with casts,
> > which makes the function @system,
> > which must then be encapsulated with a @trusted interface in order to
> > use in @safe code.
>
> Sounds right.

This is pretty much what several of us were arguing for during the discussions about shared at dconf this year.

- Jonathan M Davis

On Saturday, 12 October 2019 at 06:31:18 UTC, Jonathan M Davis wrote:
> On Friday, October 11, 2019 10:58:29 PM MDT Walter Bright via Digitalmars-d wrote:
>> On 10/2/2019 3:42 AM, Nicholas Wilson wrote:

>> > It should be that shared memory access is disabled in all contexts,
>> > which must be worked around with casts,
>> > which makes the function @system,
>> > which must then be encapsulated with a @trusted interface in order to
>> > use in @safe code.
>>
>> Sounds right.
>
> This is pretty much what several of us were arguing for during the discussions about shared at dconf this year.

How are you going to prove that @safe code does not retain nonshared-references after the lock has been released?

How does his work with array elements/slices.