shared - no read/write access

Kagamin spam at here.lot
Tue Apr 2 11:37:20 UTC 2019


On Sunday, 31 March 2019 at 07:12:08 UTC, Jonathan M Davis wrote:
> If the compiler can guarantee thread-safety, then there 
> shouldn't be a problem, and nothing needs to be made illegal, 
> but that's usually not the case. The primary exception would be 
> stuff like atomics, and that's typed with shared, so you can 
> pass shared variables to them. And it's not a problem, because 
> thread-safety is guaranteed.

False sense of thread safety already? Code is not magically 
thread safe because it uses atomics, they are only a tool. Thread 
safety is a global property and can't be easily provided on low 
level alone. But added churn can increase mistakes because of 
increased cognitive load.

> In the cases where synchronization _is_ needed, then those 
> operations should be illegal, requiring the programmer to 
> protect the object appropriately and then cast away shared to 
> operate on it while it's protected. That way, nothing marked as 
> shared is violating thread-safety, and the code where there is 
> a risk of violating thread-safety is @system. So, it becomes 
> fairly easy to grep for the portions of the code where you need 
> to worry about threading bugs.

@safe code might be disallowed to access shared data, that's 
understandable, but like for @system, it's difficult to provide 
protection for shared code that can pull its weight.

Also greppability implies that casting away shared is not really 
inevitable, it's needed if you want to apply algorithm that was 
written for thread local data, but keeping data and methods as 
shared will help communicate that it's not an ordinary thing 
happening here (a use case for private shared methods).


More information about the Digitalmars-d mailing list