On Wednesday, 2 October 2019 at 10:42:48 UTC, 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.

I don't think so. How?

On Wednesday, 2 October 2019 at 11:49:48 UTC, Atila Neves wrote:
> @system code can always cast away shared.

It's justified for @safe code, because safety is mandatory there, but not for system code. Access to shared data is well within semantics of system code. System code is even intended to access shared data because safe code can't do it in general case.

On Thursday, 3 October 2019 at 09:29:28 UTC, Kagamin wrote:
> On Wednesday, 2 October 2019 at 11:49:48 UTC, Atila Neves wrote:
>> @system code can always cast away shared.
>
> It's justified for @safe code, because safety is mandatory there, but not for system code. Access to shared data is well within semantics of system code. System code is even intended to access shared data because safe code can't do it in general case.

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.

On 10/1/2019 1:54 PM, rikki cattermole wrote:
> On 02/10/2019 9:31 AM, Walter Bright wrote:
>> On 10/1/2019 4:21 AM, rikki cattermole wrote:
>>> This DIP will need to detail how it does (and doesn't) interact with methods with the shared attribute on it, along with examples of the shared qualifier on a struct/class.
>>
>> The DIP does not change how `shared` is part of the type system, and does not change how `shared` affects the types of structs or classes or instances of them.
> 
> Okay, if we get a statement to that affect in the DIP, maybe with an example then nobody can interpret it wrong :)

Ok.


>>> As it stands, if I was to implement it, I could interpret the DIP to only affect globals.
>>
>> `shared` isn't a storage class, it's a type constructor, so I don't see how you could infer that.
> 
> Okay in that case, the spec needs updating. Because right now it is listed as part of `StorageClass` along with `const`.

While const appears in the grammar as a storage class, mainly for programmer convenience, it is a type constructor.

On 10/2/2019 10:21 AM, Manu wrote:
> On Wed, Oct 2, 2019 at 2:10 AM Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On 10/1/2019 11:30 PM, Manu wrote:
>>> I'm confused, which is it, A or B? I presume B, and my prior commentary applies.
>>
>> A
> 
> In that case, I don't understand the only code shown in the DIP; you
> show freely reading from and assigning to a shared int... that should
> be an error, and there should be atomicLoad/astomicStore in those
> locations?
> 

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.

On 10/2/2019 10:25 AM, Manu wrote:
> Also the text: "Atomic reads perform an acquire operation, writes
> perform a release
> operation, and read-modify-write performs an acquire, then a
> modification, and then a release."
> 
> What does that mean? I don't know what that's talking about.
> Please correct the DIP so we can understand it.

That follows the usage pattern in the C++ memory model documentation. I agree it is hard to follow, but it is normal jargon for those familiar with the subtleties of multi-threaded memory models.

I have written a spec PR that starts to formally define the memory model for D, but it's been sitting there for a long time and nobody wants to touch it. I don't think a DIP is the right place for it.

I see no reason to deviate from the C++ memory model semantics.

On 10/1/2019 3:07 PM, ag0aep6g wrote:
> On 01.10.19 22:34, Walter Bright wrote:
>> Actually, shared operations would no longer be generated from the syntax. They'd all be done with library functions
> 
> To clarify, we're going to get this(?):
> 
>      shared int x;
>      void main()
>      {
>          x = 42; /* error */
>      }

Yes.


> You should change the first sentence of the DIP then. It says: "Reads and writes to data typed as shared are made atomic where the target CPU supports atomic operations".
> 
>  From that sentence I would very much expect the code be accepted and generate an atomic write.

I agree it's confusing.

On 10/1/2019 1:47 PM, 12345swordy wrote:
> On Tuesday, 1 October 2019 at 20:35:51 UTC, Walter Bright wrote:
>> On 10/1/2019 9:08 AM, 12345swordy wrote:
>>> There is no detail on how is this going to be implemented.
>>
>> It'll disallow direct translation of operators to code, instead the user will have to call core.atomic library functions to do it, and the compiler may treat those as intrinsics.
> 
> Does this mean that the user can rollout their own custom implementation?

Yes, as they can today.

On Thu., 3 Oct. 2019, 8:45 pm Walter Bright via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On 10/2/2019 10:25 AM, Manu wrote:
> > Also the text: "Atomic reads perform an acquire operation, writes
> > perform a release
> > operation, and read-modify-write performs an acquire, then a
> > modification, and then a release."
> >
> > What does that mean? I don't know what that's talking about. Please correct the DIP so we can understand it.
>
> That follows the usage pattern in the C++ memory model documentation. I
> agree it
> is hard to follow, but it is normal jargon for those familiar with the
> subtleties of multi-threaded memory models.
>

I understand the language used, I have no idea how it applies to this DIP, specifically because I'm still not sure what it does, since various paragraphs and the example contradict each other.

I look forward to a revision that's easy to follow.

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.