On Monday, 2 December 2024 at 21:55:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> As a type qualifier/storage class, ``shared`` should be called ``atomic``.

`shared` is more accurate. Atomic ops are not the only way intended to mutate `shared` data. In fact atomic ops can be slower.

> If you use it to indicate anything other than the variable can only be accessed/mutated via atomic operations, you are at best lieing to yourself about the native memory model.
>
> All memory is owned by the process, until proven otherwise. Which is the exact opposite of what ``shared`` implies.

`shared` - shared (i.e. accessible) across threads.

On 04/12/2024 6:37 AM, Nick Treleaven wrote:
>     If you use it to indicate anything other than the variable can only
>     be accessed/mutated via atomic operations, you are at best lieing to
>     yourself about the native memory model.
> 
>     All memory is owned by the process, until proven otherwise. Which is
>     the exact opposite of what |shared| implies.
> 
> |shared| - shared (i.e. accessible) across threads.

That is already true. You don't need a type qualifier to tell you that.

What you need the compiler assistance for, is to tell you that it is NOT accessible to multiple threads.

On 12/3/24 9:47 AM, Richard (Rikki) Andrew Cattermole wrote:
> On 04/12/2024 6:37 AM, Nick Treleaven wrote:

>> |shared| - shared (i.e. accessible) across threads.
>
> That is already true.

That conflicts with my knowledge of data being thread-local by default in D.

> You don't need a type qualifier to tell you that.
>
> What you need the compiler assistance for, is to tell you that it is NOT
> accessible to multiple threads.

I think you are objecting to D's thread-local by default decision but I'm not sure. :)

Ali

On 04/12/2024 11:20 AM, Ali Çehreli wrote:
> On 12/3/24 9:47 AM, Richard (Rikki) Andrew Cattermole wrote:
>  > On 04/12/2024 6:37 AM, Nick Treleaven wrote:
> 
>  >> |shared| - shared (i.e. accessible) across threads.
>  >
>  > That is already true.
> 
> That conflicts with my knowledge of data being thread-local by default in D.
> 
>  > You don't need a type qualifier to tell you that.
>  >
>  > What you need the compiler assistance for, is to tell you that it is NOT
>  > accessible to multiple threads.
> 
> I think you are objecting to D's thread-local by default decision but I'm not sure. :)
> 
> Ali

You are thinking of globals, which are by default TLS yes.
No objection to that here.

What owned by a thread means is that a pointer is guaranteed to only be accessible by that thread. I.e. the cpu will segfault if you try to access it from another thread.

Current CPU's don't offer this protection, so it would have to be proven by the compiler using language features instead.

On Tuesday, 3 December 2024 at 23:16:00 UTC, Richard (Rikki) Andrew Cattermole wrote:
> What owned by a thread means is that a pointer is guaranteed to only be accessible by that thread. I.e. the cpu will segfault if you try to access it from another thread.

My experience is that aside from thread-local module globals, all other objects you create can be subsequently cast to shared and then sent on to another thread.  It can be accessed on the receiving thread as such, or cast back to un-shared and used as just another private data structure.

In fact, parts of Phobos will not work with objects having a shared attribute.  So you have to be careful about transferring ownership for such data structures, and verifying your code path guarantees exclusive access before casting it back to unshared.

Andy