On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
>> If something might be used by someone else it's better not to touch it, unless one has confirmation it is not used by someone else.
>> 
>> This is what shared has to enforce.
>
> Yes.  But how can the compiler statically verify this?  Because if it cannot be statically verified, then somewhere along the line we have to trust the programmer. Ergo, it's programming by convention, and we all know how effective that is.
>
and that is exactly what shared is currently doing. Adding the rw restriction at least adds a protection for inadvertantly changing a shared object, a thing that doesn't exist now.

What cracks me up with Manu's proposal is that it is its simplicity and lack of ambition that is criticized the most. shared is a clusterfuck, according to what I gathered from the forum, I never had yet to use it in my code. Manu's idea makes it a little less of a clusterfuck, and people attack the idea because it doesn't solve all and everything that's wrong with shared. Funny.

On Thu., 18 Oct. 2018, 5:05 am Patrick Schluter via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
> >> If something might be used by someone else it's better not to touch it, unless one has confirmation it is not used by someone else.
> >>
> >> This is what shared has to enforce.
> >
> > Yes.  But how can the compiler statically verify this?  Because if it cannot be statically verified, then somewhere along the line we have to trust the programmer. Ergo, it's programming by convention, and we all know how effective that is.
> >
> and that is exactly what shared is currently doing. Adding the rw restriction at least adds a protection for inadvertantly changing a shared object, a thing that doesn't exist now.
>
> What cracks me up with Manu's proposal is that it is its simplicity and lack of ambition that is criticized the most. shared is a clusterfuck, according to what I gathered from the forum, I never had yet to use it in my code. Manu's idea makes it a little less of a clusterfuck, and people attack the idea because it doesn't solve all and everything that's wrong with shared. Funny.
>

Elaborate on this... It's clearly over-ambitious if anything.
What issues am I failing to address? I'm creating a situation where using
shared has a meaning, is safe, and doesn't require any unsafe interactions,
no casts, etc, for users at any level above the bare metal tooling... How
would you improve on that proposition?

>

On Wednesday, 17 October 2018 at 21:12:49 UTC, Stefan Koch wrote:
> Hi,
>
> reading the other shared thread  "shared - i need to be useful"(https://forum.dlang.org/thread/mailman.4299.1539629222.29801.digitalmars-d@puremagic.com)
>
> let me to an important realisation concerning the reason shareding data across threads is so unintuitve and hard to get right.
> The reason is that sharing in the real world has nothing to do with using something and the same time.
> For example: If I share my flat with another person, that person, while occupying the same flat as me, cannot actually occupy the same space. It is physically impossible.
>
> In other words sharing does not mean for multiple entities to own something it's rather about diving and managing the (temporary) ownership of fragments.
>
> Therefore if ownership is unclear sharing is impossible.
> The safest default for something shared with unclear ownership is to view it as untouchable/unreadble/unwritable until ownership is established.

My understanding is that the "shared" keyword can be useful especially with array types that are operated on by multiple threads.  Some algorithms put together data following specific rules on how that data can be fragmented.

Imagine a simple algorithm that does logic on very long numbers, split into bytes.  One multi-threaded implementation may use 4 threads.  The first operating on bytes 0, 4, 8, etc.  The second operating on bytes 1, 5, 9, etc.

In this case, a mutex or lock isn't actually needed, because the algorithm itself assures that threads don't collide.

It's an over-simplification, but I think this is basically what the prime-number finding algorithm by Jabari Zakiya is doing.

On Thursday, 18 October 2018 at 16:31:33 UTC, Vijay Nayar wrote:

> Imagine a simple algorithm that does logic on very long numbers, split into bytes.  One multi-threaded implementation may use 4 threads.  The first operating on bytes 0, 4, 8, etc.  The second operating on bytes 1, 5, 9, etc.
>
> In this case, a mutex or lock isn't actually needed, because the algorithm itself assures that threads don't collide.

Yes, they do collide. You just turned your cache into a giant clusterf**k. Keyword: MESIF.

Pardon the snarkiness, I probably need to get some air from that other shared thread.

On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
> On Thu., 18 Oct. 2018, 5:05 am Patrick Schluter via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
>
>> On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
>> >> If something might be used by someone else it's better not to touch it, unless one has confirmation it is not used by someone else.
>> >>
>> >> This is what shared has to enforce.
>> >
>> > Yes.  But how can the compiler statically verify this?  Because if it cannot be statically verified, then somewhere along the line we have to trust the programmer. Ergo, it's programming by convention, and we all know how effective that is.
>> >
>> and that is exactly what shared is currently doing. Adding the rw restriction at least adds a protection for inadvertantly changing a shared object, a thing that doesn't exist now.
>>
>> What cracks me up with Manu's proposal is that it is its simplicity and lack of ambition that is criticized the most. shared is a clusterfuck, according to what I gathered from the forum, I never had yet to use it in my code. Manu's idea makes it a little less of a clusterfuck, and people attack the idea because it doesn't solve all and everything that's wrong with shared. Funny.
>>
>
> Elaborate on this... It's clearly over-ambitious if anything.
> What issues am I failing to address? I'm creating a situation where using
> shared has a meaning, is safe, and doesn't require any unsafe interactions,
> no casts, etc, for users at any level above the bare metal tooling... How
> would you improve on that proposition?

No, your proposition is not the issue here. The problem I see is the expectation people have with what shared is supposed to do. I have the impression from reading in this forum about shared that people expect that just putting a shared in front of a variable will solve all the concurrency problems in existance.
Your proposition doesn't want to address this utopic goal and that is a good thing imo. Adding that restriction that you propose makes explicit what was implied but not clearly stated until now.
I'm not good enough in D to add more than a meta reflexion on the subject so I will not follow up on that. I often have the impression that a lot of things are going slower than necessary because a mentality where the perfect is in the way of good.

On Thursday, 18 October 2018 at 17:01:46 UTC, Stanislav Blinov wrote:
> On Thursday, 18 October 2018 at 16:31:33 UTC, Vijay Nayar wrote:
>
>> Imagine a simple algorithm that does logic on very long numbers, split into bytes.  One multi-threaded implementation may use 4 threads.  The first operating on bytes 0, 4, 8, etc.
>>  The second operating on bytes 1, 5, 9, etc.
>>
>> In this case, a mutex or lock isn't actually needed, because the algorithm itself assures that threads don't collide.
>
> Yes, they do collide. You just turned your cache into a giant clusterf**k. Keyword: MESIF.

In that case partitioning in cache line sizes is the least that has to be done.

On Thu, Oct 18, 2018 at 07:09:42PM +0000, Patrick Schluter via Digitalmars-d wrote: [...]
> I often have the impression that a lot of things are going slower than necessary because a mentality where the perfect is in the way of good.

That is indeed an all-too-frequent malady around these parts, sad to say. Which has the sad consequence that despite all efforts, there are still unfinished areas in D, and promises that haven't materialized in years (like multiple alias this).

Still, the parts of D that are working well form a very powerful and comfortable-to-use language.  Not quite the ideal we wish it to be, but IMO much closer than any other language I've seen yet.  Recently I began dabbling in Android programming, and the one thing that keeps sticking out to me is how painful writing Java is.  Almost every day of writing Java code has me wishing for this or that feature in D.  Slices. Closures.  Meta-programming.  I found most of my time spent fighting with language limitations rather than make progress with the problem domain.  Eventually I resorted to generating Java code from D for some fo the most painful repetitive parts, and the way things are looking, I'm likely to be doing a lot more of that.  I fear the way things are going will have be essentially writing a D to Java compiler at some point!

D may not be perfect in many ways, but it's still one of the best languages out there right now, IMO.


T

-- 
Give me some fresh salted fish, please.

On Thursday, 18 October 2018 at 19:09:42 UTC, Patrick Schluter wrote:
> On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
>>
>> Elaborate on this... It's clearly over-ambitious if anything.
>> What issues am I failing to address? I'm creating a situation where using
>> shared has a meaning, is safe, and doesn't require any unsafe interactions,
>> no casts, etc, for users at any level above the bare metal tooling... How
>> would you improve on that proposition?
>
> No, your proposition is not the issue here. The problem I see is the expectation people have with what shared is supposed to do. I have the impression from reading in this forum about shared that people expect that just putting a shared in front of a variable will solve all the concurrency problems in existance.

I think you hit the nail on the head here.

When shared stood up in its current form,  expectation was made "this will be threadsafe automatically - we'll figure out how in the future". Because it works for global variables. But it doesn't seem like an expectation we can deliver on.

(I have no direct reference to this but that was certainly my impression)

> Your proposition doesn't want to address this utopic goal and that is a good thing imo. Adding that restriction that you propose makes explicit what was implied but not clearly stated until now.
> I'm not good enough in D to add more than a meta reflexion on the subject so I will not follow up on that. I often have the impression that a lot of things are going slower than necessary because a mentality where the perfect is in the way of good.

On Thursday, 18 October 2018 at 20:10:18 UTC, Erik van Velzen wrote:

> When shared stood up in its current form,  expectation was made "this will be threadsafe automatically - we'll figure out how in the future".

It never was like that. At all. I don't think either Walter or Andrei are idiots, do you?

> Because it works for global variables. But it doesn't seem like an expectation we can deliver on.
>
> (I have no direct reference to this but that was certainly my impression)

Your impression was wrong. Open e.g. TDPL and read up on `shared` how it was envisioned back then.