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@**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
