On 16 November 2012 12:09, Pragma Tix <bizprac@orange.fr> wrote:
On Friday, 16 November 2012 at 09:24:22 UTC, Manu wrote:
On 15 November 2012 17:17, Andrei Alexandrescu <
SeeWebsiteForEmail@erdani.org> wrote:

On 11/15/12 1:08 AM, Manu wrote:

On 14 November 2012 19:54, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@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

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.