<div dir="ltr"><div dir="ltr">On Tue, Aug 4, 2020 at 6:26 PM Simen Kjærås via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, 4 August 2020 at 07:38:26 UTC, Sebastiaan Koppe wrote:<br>
> On Monday, 3 August 2020 at 21:56:34 UTC, Manu wrote:<br>
>> Shared recently received a `-preview` which makes it really <br>
>> mean something;<br>
>> this is what shared means:<br>
>> 1. The data is shared; therefore, it is invalid to read or <br>
>> write that<br>
>> memory.<br>
>> 2. The reason this is useful as an attribute, is because you <br>
>> are able to<br>
>> attribute methods. Ability to author a set of threadsafe <br>
>> methods and<br>
>> clearly distinguish them from non-threadsafe methods is a <br>
>> powerful<br>
>> advantage over C++.<br>
><br>
> For some reason I often end up with multiple threads and the <br>
> coordination that comes with it. Shared has been very helpful <br>
> for me and I am using no. 2 with good success.<br>
><br>
> There is just one thing about shared I don't understand. If I <br>
> design my object such that the non-shared methods are to be <br>
> used thread-local and the shared methods from any thread, it <br>
> follows that I should be able to call said shared methods from <br>
> both a shared and non-shared instance of that object.<br>
><br>
> Often I workaround it be introducing a non shared method that <br>
> forwards to the shared method by means of casting.<br>
<br>
With DIP1024, any type should be implicitly castable to shared. <br>
This means you should always be able to call shared methods on <br>
any object. Far as I can see, this is not implemented.<br>
<br>
For a type with no thread-safe interface that means anyone with a <br>
shared reference to it can call absolutely no methods on it, and <br>
not read or write any of its fields. Kinda useless, but that's <br>
the point. If you want to manipulate it, you will need to cast <br>
away shared, which is non-@safe and a red flag.<br>
<br>
For a type with a thread-safe interface, there may be methods <br>
that can't be called, but some subset will be callable. These <br>
must be written such that they are thread-safe, and any <br>
non-shared methods must be written such that they do not break <br>
the thread-safety of shared methods (but non-shared methods may <br>
be non-thread-safe if called on multiple threads, since that <br>
should not happen).<br>
<br>
In other words, DIP1024 assumes you will have at most one <br>
non-shared reference to an object, and that no methods on an <br>
object are written in such a way that they break thread-safety <br>
under this assumption.<br>
<br>
--<br>
   Simen<br></blockquote><div><br></div><div>I don't think what you describe has anything to do with DIP1024.</div><div>What you're describing is the scheme I was arguing for 1-2 years ago, but Walter rejected it and presented DIP1024 instead.</div><div>DIP1024 was a step in the right direction, so I supported it at that time, but it doesn't change any definitions about thread-safety of methods, and it's not a complete solution. It just adds the restrictions that should have been there from the start; that is, `shared` has no read or write access to data.</div></div></div>