Something needs to happen with shared, and soon.

Manu turkeyman at gmail.com
Fri Nov 16 01:24:13 PST 2012


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121116/b60964db/attachment.html>


More information about the Digitalmars-d mailing list