Thread overview
Re: Shared Hell
Oct 29, 2009
Kagamin
Oct 29, 2009
Kagamin
Oct 29, 2009
Walter Bright
October 29, 2009
Walter Bright 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.

Shared code perfectly deals with unshared data (it's not guaranteed that shared data is accessed by more than one thread). In other words unshared data is implicitly castable to shared.
October 29, 2009
Kagamin Wrote:

> Walter Bright 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.
> 
> Shared code perfectly deals with unshared data (it's not guaranteed that shared data is accessed by more than one thread). In other words unshared data is implicitly castable to shared.

Uh... this post was a little fast, ignore it, please.
October 29, 2009
Kagamin wrote:
> Walter Bright 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.
> 
> Shared code perfectly deals with unshared data (it's not guaranteed
> that shared data is accessed by more than one thread). In other words
> unshared data is implicitly castable to shared.

Unfortunately, there is a subtle problem with that that makes such implicit casts unsafe. Shared data can be handed off to other threads. So if thread local data is implicitly cast to shared, then it can be handed off to other threads. Meaning it is no longer guaranteed to be thread local.