Something needs to happen with shared, and soon.

[Manu]

On 16 November 2012 12:09, Pragma Tix <bizprac at orange.fr> wrote:

> 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@**e**
>>>> rdani.org <http://erdani.org><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<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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121116/9e050c63/attachment.html>