• Kagamin <spam here.lot> Oct 29 2009
• Christopher Wright <dhasenan gmail.com> Oct 29 2009
• "Steven Schveighoffer" <schveiguy yahoo.com> Oct 29 2009

Kagamin <spam here.lot> writes:

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.

Christopher Wright <dhasenan gmail.com> writes:

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.


 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.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 Oct 2009 07:25:20 -0400, Christopher Wright  
<dhasenan 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.


 expense. I would have looked into optimizing this expense away rather  
 than punting the problem to the programmer.


 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