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