On Saturday, 17 November 2012 at 13:22:23 UTC, Michel Fortin wrote:
> On 2012-11-16 18:56:28 +0000, Dmitry Olshansky <dmitry.olsh@gmail.com> said:
>
>> 11/16/2012 5:17 PM, Michel Fortin пишет:
>>> In case you want to protect two variables (or more) with the same mutex.
>>> For instance:
>>> 
>>>     Mutex m;
>>>     synchronized(m) int next_id;
>>>     synchronized(m) Object[int] objects_by_id;
>>> 
>> 
>> Wrap in a struct and it would be even much clearer and safer.
>> struct ObjectRepository {
>> 	int next_id;
>> 	Object[int] objects_by_id;
>> }
>> //or whatever that combination indicates anyway
>> synchronized ObjectRepository objeRepo;
>
> I guess that'd be fine too.

<snip>

That solution does not work in the general case. More specifically any graph-like data structure. E.g a linked-lists, trees, etc..
Think for example an insert to a shared AVL tree.

On 2012-11-19 09:31:46 +0000, "foobar" <foo@bar.com> said:

> On Saturday, 17 November 2012 at 13:22:23 UTC, Michel Fortin wrote:
>> On 2012-11-16 18:56:28 +0000, Dmitry Olshansky <dmitry.olsh@gmail.com> said:
>> 
>>> 11/16/2012 5:17 PM, Michel Fortin пишет:
>>>> In case you want to protect two variables (or more) with the same mutex.
>>>> For instance:
>>>> 
>>>>     Mutex m;
>>>>     synchronized(m) int next_id;
>>>>     synchronized(m) Object[int] objects_by_id;
>>>> 
>>> 
>>> Wrap in a struct and it would be even much clearer and safer.
>>> struct ObjectRepository {
>>> 	int next_id;
>>> 	Object[int] objects_by_id;
>>> }
>>> //or whatever that combination indicates anyway
>>> synchronized ObjectRepository objeRepo;
>> 
>> I guess that'd be fine too.
> 
> <snip>
> 
> That solution does not work in the general case. More specifically any graph-like data structure. E.g a linked-lists, trees, etc..
> Think for example an insert to a shared AVL tree.

No solution will be foolproof in the general case unless we add new type modifiers to the language to prevent escaping references, something Walter is reluctant to do. So whatever we do with mutexes it'll always be a leaky abstraction. I'm not too trilled by this either.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

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@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.