valid uses of shared

[Artur Skawina]

On 06/12/12 00:00, Artur Skawina wrote:
> On 06/11/12 22:21, Steven Schveighoffer wrote:
>>>> Now, would you agree that:
>>>>
>>>> auto v1 = synchronized p.i;
>>>>
>>>> might be a valid mechanism?  In other words, assuming p is lockable, synchronized p.i locks p, then reads i, then unlocks p, and the result type is unshared?

What I think you want is relatively simple, something like this:

   struct synchronized(m) S {
      int i;
      void *p;
      Mutex m;
   }

and then for S to be completely opaque, unless inside a synchronized
statement. So

   S* s = ...
   auto v1 = s.i; // "Error: access to 's.i' requires synchronization"
   synchronized (s) {
      auto v2 = s.i;
      // ...
   }
   auto v3 = s.p; // "Error: access to 's.p' requires synchronization"

and there's no 'shared' involved at all. 

Provided that no reference to a locked 's' can escape this should be
enough to solve this problem.

Preventing the leaks while not unnecessarily restricting what can be done
inside the synchronized block would be a different problem. The obvious
solution would be to treat all refs gotten from or via 's' as scoped (and
trust the programmer; with time the enforcing can be improved), but
sometimes you will actually want to remove objects from a synchronized
container - so that must be possible too.

artur