Something needs to happen with shared, and soon.

Pragma Tix bizprac at orange.fr
Fri Nov 16 06:25:10 PST 2012


On Friday, 16 November 2012 at 10:59:02 UTC, Manu wrote:
> 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.

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.




More information about the Digitalmars-d mailing list