Shared Hell

[Steven Schveighoffer]

On Thu, 29 Oct 2009 07:25:20 -0400, Christopher Wright  
<dhasenan at gmail.com> wrote:

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

Let's say your shared method your attempting to analyze calls an obscure  
shared method:

int foo(shared C c);

How do you determine if it can be called without the 'shared' qualifier?   
This is one of the problems with not importing from compiled interface  
files.

-Steve