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