<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat., 22 Jun. 2019, 9:40 am Walter Bright via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com">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 6/21/2019 5:07 AM, Manu wrote:<br>
> There is no "between threads" unless you have already entered @trusted land.<br>
> The reason for my proposal in the OP is precisely to prevent passing<br>
> data to other threads, that's the key that makes this promotion safe.<br>
<br>
Scope doesn't do that. I keep saying this. But the premise is strange, anyway, <br>
as why would you want to convert a reference to shared if not to bass it to <br>
another thread?<br>
<br>
<br>
> Can you show how you managed to get a ref to another thread without<br>
> entering @trusted?<br>
There's no such thing as a ref to another thread. You can pass a ref to another <br>
thread in a scope function, as long as the ref doesn't survive the scope of foo().<br>
<br>
The compiler cannot check that, though, and so cannot bless the implicit <br>
conversion to shared. I've said this 4 or 5 times now.<br>
<br>
<br>
> There's no possibility of the synchronisation<br>
> issue arising unless there's some way to escape a scope ref to another<br>
> thread, which scope prevents.<br>
<br>
You're inventing semantics for scope that I've repeatedly told you are not there.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">I've asked you 5 or 6 times to show how to pass a pointer to another thread without violating scope.</div><div dir="auto">Can you show it? You keep saying you can.</div><div dir="auto"><br></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">
> We're not talking about atomic reads here, we're talking about memory barriers.<br>
<br>
I recommend watching:<br>
<br>
<a href="https://www.youtube.com/watch?v=A8eCGOqgvH4" rel="noreferrer noreferrer" target="_blank">https://www.youtube.com/watch?v=A8eCGOqgvH4</a><br>
<a href="https://www.youtube.com/watch?v=KeLBd2EJLOU" rel="noreferrer noreferrer" target="_blank">https://www.youtube.com/watch?v=KeLBd2EJLOU</a><br>
<br>
as you and I are not speaking the same language. In particular the sections on <br>
how atomics create sequentially consistent data-race-free reads and writes of <br>
variables. Not needing to read x atomically after foo() ends is just plain wrong.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">You need an acquire fence before the function returns, it's trivial.</div><div dir="auto">In many cases though you don't need one, because you may have already required one to determine that the workload is complete in the first place.</div><div dir="auto">Don't attempt this in the @system language. Just let it be, we know what we're doing.</div><div dir="auto"><br></div><div dir="auto">If you want @safe expansion, that's future work, and I personally couldn't care less about that work. I can create safe libraries with @trusted functions, and I could do it _right now_.</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>