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