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.
