On 16 November 2012 12:09, Pragma Tix <span dir="ltr"><<a href="mailto:bizprac@orange.fr" target="_blank">bizprac@orange.fr</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Friday, 16 November 2012 at 09:24:22 UTC, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On 15 November 2012 17:17, Andrei Alexandrescu <<br>
<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On 11/15/12 1:08 AM, Manu wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On 14 November 2012 19:54, Andrei Alexandrescu<br></div>
<<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a> <mailto:<a href="mailto:SeeWebsiteForEmail@" target="_blank">SeeWebsiteForEmail@</a>**<a href="http://erdani.org" target="_blank">e<u></u>rdani.org</a><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@<u></u>erdani.org</a>><div>
<div class="h5"><br>
>><br>
<br>
wrote:<br>
    Yah, the whole point here is that we need something IN THE LANGUAGE<br>
    DEFINITION about atomicLoad and atomicStore. NOT IN THE<br>
IMPLEMENTATION.<br>
<br>
    THIS IS VERY IMPORTANT.<br>
<br>
<br>
I won't outright disagree, but this seems VERY dangerous to me.<br>
<br>
You need to carefully study all popular architectures, and consider that<br>
if the language is made to depend on these primitives, and the<br>
architecture doesn't support it, or support that particular style of<br>
implementation (fairly likely), than D will become incompatible with a<br>
huge number of architectures on that day.<br>
<br>
</div></div></blockquote><div><div class="h5">
<br>
All contemporary languages that are serious about concurrency support<br>
atomic primitives one way or another. We must too. There's no two ways<br>
about it.<br>
<br>
[snip]<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Side note: I still think a convenient and fairly practical solution is<br>
to make 'shared' things 'lockable'; where you can lock()/unlock() them,<br>
and assignment to/from shared things is valid (no casting), but a<br>
runtime assert insists that the entity is locked whenever it is<br>
accessed.<br>
<br>
</blockquote>
<br>
This (IIUC) is conflating mutex-based synchronization with memory models<br>
and atomic operations. I suggest we postpone anything related to that for<br>
the sake of staying focused.<br>
</div></div></blockquote>
<br>
<br><div class="im">
I'm not conflating the 2, I'm suggesting to stick with the primitives that<br>
are already present and proven, at least for the time being.<br>
This thread is about addressing the problem in the short term, long term<br>
plans can simmer until they're ready, but any moves in the short term<br>
should make use of the primitives available and known to work, ie, don't<br>
try and weave in language level support for architectural atomic operations<br>
until there's a thoroughly detailed plan, and it's validated against many<br>
architectures so we know what we're losing.<br>
Libraries can already be written to do a lot of atomic stuff, but I still<br>
agree with the OP that shared should be addressed and made more useful in<br>
the short term, hence my simplistic suggestion; runtime assert that a<br>
shared object is locked when it is read/written, and consequently, lift the<br></div>
cast requirement, making it compatible with templates.<br>
</blockquote>
<br>
Seems to me that Soenkes's library solution went into to right direction<br>
<br>
<a href="http://forum.dlang.org/post/k831b6$1368$1@digitalmars.com" target="_blank">http://forum.dlang.org/post/<u></u>k831b6$1368$1@digitalmars.com</a><br>
</blockquote></div><br></div><div class="gmail_extra">Looks reasonable to me, also <span style="font-family:arial,sans-serif;font-size:13px">Dmitry Olshansky and luka have both made suggestions that look good to me aswell.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">I think the only problem with all these is that they don't really feel like a feature of the language, just some template that's not yet even in the library.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">D likes to claim that it is strong on concurrency, with that in mind, I'd expect to at least see one of these approaches polished, and probably even nicely sugared.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">That's a minimum that people will expect, it's a proven, well known pattern that many are familiar with, and it can be done in the language right now.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">Sugaring a feature like that is simply about improving clarity, and reducing friction for users of something that D likes to advertise as being a core feature of the language.</span></div>