<div class="gmail_quote">On Tue, Oct 18, 2011 at 1:11 AM, Benjamin Thaut <span dir="ltr"><<a href="mailto:code@benjamin-thaut.de">code@benjamin-thaut.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am 18.10.2011 08:03, schrieb Andrew Wiley:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Oct 18, 2011 at 12:53 AM, Benjamin Thaut <<a href="mailto:code@benjamin-thaut.de" target="_blank">code@benjamin-thaut.de</a><br></div><div class="im">
<mailto:<a href="mailto:code@benjamin-thaut.de" target="_blank">code@benjamin-thaut.de</a><u></u>>> wrote:<br>
<br>
Am 17.10.2011 22:43, schrieb Michel Fortin:<br>
<br>
On 2011-10-17 20:33:59 +0000, Andrew Wiley<br></div><div><div></div><div class="h5">
<<a href="mailto:wiley.andrew.j@gmail.com" target="_blank">wiley.andrew.j@gmail.com</a> <mailto:<a href="mailto:wiley.andrew.j@gmail.com" target="_blank">wiley.andrew.j@gmail.<u></u>com</a>>> said:<br>
<br>
<br>
Okay, I realize there have been some discussions about this,<br>
but I have a<br>
few questions about shared delegates because right now they are<br>
definitely<br>
broken, but I'm not sure how.<br>
Take this code example:<br>
<br>
synchronized class Thing {<br>
void doSomeWork(void delegate() work) {<br>
work();<br>
}<br>
void work() {}<br>
}<br>
<br>
void main() {<br>
auto th = new Thing();<br>
th.doSomeWork(&th.work);<br>
}<br>
<br>
This doesn't compile because the type of "&th.work" is "void<br>
delegate()<br>
shared", which cannot be cast implicitly to "void delegate()".<br>
My first question would be whether that type is correct.<br>
It's true<br>
that the<br>
data pointer of the delegate points to a shared object, but<br>
given that<br>
the<br>
function locks it, does that really matter in this case? I<br>
guess I'm just<br>
not clear on the exact meaning of "shared" in general, but<br>
it seems like<br>
whether the data is shared or not is irrelevant when the<br>
delegate<br>
points to<br>
a public member of a synchronized class. If it was a<br>
delegate pointing<br>
to a<br>
private/protected member (which should be illegal in this<br>
case), that<br>
would<br>
not be true.<br>
If that type is correct, the problem is that "void<br>
delegate() shared"<br>
doesn't parse as a type (there is a workaround because you<br>
can create<br>
variables of this type through alias and typeof).<br>
<br>
What, exactly, is wrong here?<br>
<br>
<br>
I think what's wrong is that a shared delegate should implicitly<br>
convert<br>
to a non-shared one. The delegate is shared since it can be called<br>
safely from any thread, and making it non-shared only prevent<br>
you from<br>
propagating it to more thread so it's not harmful in any way.<br>
<br>
<br>
I reported this exact issue already a few months ago and simply<br>
didn't get any comment on it. If you really try to use shared to are<br>
going to hit more such problems.<br>
<br>
See the shared section of my blogpost:<br></div></div>
<a href="http://3d.benjamin-thaut.de/?__p=18" target="_blank">http://3d.benjamin-thaut.de/?_<u></u>_p=18</a> <<a href="http://3d.benjamin-thaut.de/?p=18" target="_blank">http://3d.benjamin-thaut.de/?<u></u>p=18</a>><div class="im">
<br>
<br>
<br>
Ah, I was looking through the bug reports and didn't see this exact bug.<br>
Did I just fail at searching, or should I file it?<br>
<br>
</div></blockquote>
<br>
I didn't file it yet, so file it. I do however think that currently there is no intention in changing the way shared works.<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>This much is clearly a bug, and Michel's explanation of how shared delegates should work makes a lot of sense. </div>
<div>As for the synchronized classes that synchronize access to not-really-shared members, well, I don't think that's changing. The problem is that the compiler can't *guarantee* that the reference you hold is the only reference. TDPL has a discussion of why an "A owns B, so A's lock should be good enough for B" wasn't implemented.</div>
<div>As for the overloading on shared, the idea there was that you should really either be multithreaded or not - trying to implement both shared and non-shared versions of code is generally a bad idea and quite bug prone. If it *might* be shared, just synchronize it. Premature optimization is the root of quite a bit of evil, and trying to make some things thread safe and some things not is walking a tightrope without any sense of balance - you won't know when you fall, you'll just see the corruption when you hit the floor.</div>
</div>