On Friday, 16 November 2012 at 10:59:02 UTC, Manu wrote:
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.
Hi Manu,
point taken. But Dimitry and Luka just made suggestions. Soenke
offers something concrete. (working right NOW) I am afraid that
we'll end up in a situation similar to the std.collections opera.
Just bla bla, and zero results. (And the collection situation
isn't solved since the very beginning of D, not to talk about
immutable collections)
Probably not En Vogue : For me Transactional Memory Management
makes sense.
