On 16 November 2012 12:09, Pragma Tix <bizp...@orange.fr> wrote: > On Friday, 16 November 2012 at 09:24:22 UTC, Manu wrote: > >> On 15 November 2012 17:17, Andrei Alexandrescu < >> seewebsiteforem...@erdani.org> wrote: >> >> On 11/15/12 1:08 AM, Manu wrote: >>> >>> On 14 November 2012 19:54, Andrei Alexandrescu >>>> <seewebsiteforem...@erdani.org <mailto:SeeWebsiteForEmail@**e** >>>> rdani.org >>>> <http://erdani.org><SeeWebsiteForEmail@**erdani.org<seewebsiteforem...@erdani.org> >>>> > >>>> >>>> >> >>>> >>>> wrote: >>>> Yah, the whole point here is that we need something IN THE LANGUAGE >>>> DEFINITION about atomicLoad and atomicStore. NOT IN THE >>>> IMPLEMENTATION. >>>> >>>> THIS IS VERY IMPORTANT. >>>> >>>> >>>> I won't outright disagree, but this seems VERY dangerous to me. >>>> >>>> You need to carefully study all popular architectures, and consider that >>>> if the language is made to depend on these primitives, and the >>>> architecture doesn't support it, or support that particular style of >>>> implementation (fairly likely), than D will become incompatible with a >>>> huge number of architectures on that day. >>>> >>>> >>> All contemporary languages that are serious about concurrency support >>> atomic primitives one way or another. We must too. There's no two ways >>> about it. >>> >>> [snip] >>> >>> Side note: I still think a convenient and fairly practical solution is >>>> to make 'shared' things 'lockable'; where you can lock()/unlock() them, >>>> and assignment to/from shared things is valid (no casting), but a >>>> runtime assert insists that the entity is locked whenever it is >>>> accessed. >>>> >>>> >>> This (IIUC) is conflating mutex-based synchronization with memory models >>> and atomic operations. I suggest we postpone anything related to that for >>> the sake of staying focused. >>> >> >> >> I'm not conflating the 2, I'm suggesting to stick with the primitives that >> are already present and proven, at least for the time being. >> This thread is about addressing the problem in the short term, long term >> plans can simmer until they're ready, but any moves in the short term >> should make use of the primitives available and known to work, ie, don't >> try and weave in language level support for architectural atomic >> operations >> until there's a thoroughly detailed plan, and it's validated against many >> architectures so we know what we're losing. >> Libraries can already be written to do a lot of atomic stuff, but I still >> agree with the OP that shared should be addressed and made more useful in >> the short term, hence my simplistic suggestion; runtime assert that a >> shared object is locked when it is read/written, and consequently, lift >> the >> cast requirement, making it compatible with templates. >> > > Seems to me that Soenkes's library solution went into to right direction > > http://forum.dlang.org/post/**k831b6$1368$1...@digitalmars.com<http://forum.dlang.org/post/k831b6$1368$1...@digitalmars.com> >
Looks reasonable to me, also Dmitry Olshansky and luka have both made suggestions that look good to me aswell. 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. 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. 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. 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.