<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Fri., 19 Oct. 2018, 3:10 am Walter Bright via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/17/2018 12:20 AM, Manu wrote:<br>
> What does it mean 'aliased' precisely?<br>
<br>
Aliasing means there are two paths to the same piece of data. That could be two <br>
pointers pointing to the same data, or one pointer to a variable that is <br>
accessible by name.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The reason I ask is because, by my definition, if you have:</div><div dir="auto">int* a;</div><div dir="auto">shared(int)* b = a;</div><div dir="auto"><br></div><div dir="auto">While you have 2 numbers that address the same data, it is not actually aliased because only `a` can access it. It is not aliased in any practical sense.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It doesn't really give us<br>
> anything in practice that we don't have in C++.<br>
<br>
It provides a standard, enforced way to distinguish shared data from unshared <br>
data, and no way to bypass it in @safe code. There's no way to do that in C++.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Right, but we can do so much better. I want shared to model "what is thread-@safe to do", because that models what you are able to do, and what API's should encourage when operating on `shared` things.<br></div><div dir="auto"><br></div><div dir="auto">Exclusively distinguishing shared and unshared data is not an interesting distinction if shared data has no access.<br></div><div dir="auto">I've been trying to say over and over; ignore what you think you know about that definition, accept my rules strictly as given (they're very simple and concise, there's only 2 rules), such that shared will mean "is threadsafe to call with this data" when applied to function args...</div><div dir="auto">Build the thought experiment outward from there. </div><div dir="auto">That's an interesting and useful definition for shared, and it leads to a framework where shared is useful in a fully @safe SMP program, and even models @safe transitions across unshared -> shared boundaries (parallel for, map/reduce, etc, fork and join style workloads), which are typical lock-free patterns.</div><div dir="auto"><br></div><div dir="auto">Lock-and-cast semantics are preserved unchanged for those that interact in the way shared is prescribed today, but strictly modeling that workflow is uninteresting, because it's unsafe by definition. I'm not losing that, but I'm trying to introduce a safe workflow that exists in complement, and my model works.<br></div><div dir="auto">I don't even know if we have a mutex defined in our codebase, we don't use them... but we can max out a 64core thread ripper.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
</div>