Something needs to happen with shared, and soon.
Pragma Tix
bizprac at orange.fr
Fri Nov 16 02:09:58 PST 2012
On Friday, 16 November 2012 at 09:24:22 UTC, Manu wrote:
> On 15 November 2012 17:17, Andrei Alexandrescu <
> SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 11/15/12 1:08 AM, Manu wrote:
>>
>>> On 14 November 2012 19:54, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org
>>> <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail at 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
More information about the Digitalmars-d
mailing list