Something needs to happen with shared, and soon.

Sönke Ludwig sludwig at outerproduct.org
Mon Nov 19 01:09:16 PST 2012


Am 19.11.2012 05:57, schrieb deadalnix:
> Le 17/11/2012 05:49, Jason House a écrit :
>> On Thursday, 15 November 2012 at 16:31:43 UTC, Sean Kelly wrote:
>>> On Nov 11, 2012, at 6:30 PM, Walter Bright
>>> <newshound2 at digitalmars.com> wrote:
>>>>
>>>> To make a shared type work in an algorithm, you have to:
>>>>
>>>> 1. ensure single threaded access by aquiring a mutex
>>>> 2. cast away shared
>>>> 3. operate on the data
>>>> 4. cast back to shared
>>>> 5. release the mutex
>>>
>>>
>>> So what happens if you pass a reference to the now non-shared object
>>> to a function that caches a local reference to it? Half the point of
>>> the attribute is to protect us from accidents like this.
>>
>> The constructive thing to do may be to try and figure out what should
>> users be allowed to do with locked shared data... I think the basic idea
>> is that no references can be escaped; SafeD rules could probably help
>> with that. Non-shared member functions might also need to be tagged with
>> their ability to be called on locked, shared data.
> 
> Nothing is safe if ownership cannot be statically proven. This is completely useless.

But you can at least prove ownership under some limited circumstances. Limited, but (without having
tested on a large scale) still practical.

Interest seems to be limited much more than those circumstances, but anyway:
http://forum.dlang.org/thread/k831b6$1368$1@digitalmars.com

(the same approach that I already posted in this thread, but in a state that should be more or less
bullet proof)


More information about the Digitalmars-d mailing list