Something needs to happen with shared, and soon.

[Jason House]

On Monday, 19 November 2012 at 04:57:16 UTC, deadalnix wrote:
> 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.

Bartosz's design was very explicit about ownership, but was 
deemed too complex for D2. Shared was kept simple, but 
underpowered.

Here's what I remember of Bartosz's design:
- Shared object members are owned by the enclosung container 
unless explicitly marked otherwise
- lockfree shared data is marked differently
- Non-lockfree shared objects required locking them prior to 
access, but did not require separate shared and non-shared code.
- No sequential consistency

I really liked his design, but I think the explicit ownership 
part was considered too complex. There may still be something 
that can be done to improve D2, but I doubt it'd be a complete 
solution.