Shared Hell

[Christopher Wright]

Kagamin wrote:
> Christopher Wright Wrote:
> 
>>> A function that accesses shared data has to put in fences. There's no 
>>> way to have the same code deal with shared and unshared code.
>> Acquiring a lock on a non-shared instance is safe, just an unnecessary 
>> expense. I would have looked into optimizing this expense away rather 
>> than punting the problem to the programmer.
> 
> Shared code can put data into *really* shared environment, which must not happen for unshared data.

Okay, but the compiler can try copying the method, removing the 'shared' 
storage class, and running semantic on the result. If that succeeds, 
you're guaranteed not to be doing anything that would be unsafe unless 
you're casting, and you can call the shared method on a local instance.

This lets you avoid whole program analysis and blacklisting unsafe 
operations.

In this case, the compiler can also point to the line of code that 
prevents the method from being marked not shared.