Shared

[Dominikus Dittes Scherkl]

On Saturday, 11 May 2019 at 12:08:00 UTC, Stefan Koch wrote:
> On Saturday, 11 May 2019 at 09:51:41 UTC, Dominikus Dittes 
> Scherkl wrote:
>> I've followed the AGM a little and think, why not go with the 
>> "disable access to shared" approach, but instead of allowing 
>> it to be casted away, introduce a "locked scope" lock { } 
>> which need to be within a function and allow access to shared 
>> variables only within such blocks?
>> It's still up to the user to ensure that such locked blocks 
>> encapsulate the semantic blocks which need to be kept together 
>> to safely modify shared variables, but at least the compiler 
>> can make sure they are not modified outside locked blocks and 
>> that at any time only one such block is executed on any 
>> thread. And such blocks should be scarce so they can be 
>> examined carefully like trusted and everything build upon is 
>> verifiable safe.
>
> And leave shared in the useless state that it currently has?
No, as I said: use the "access disabled" (outside of locked 
blocks) approach, as several people advocated for.

> + introducing a new synchronized keyword? (locked)?
Need not be a keyword. It's also possible to use Lock() and 
Unlock() functions, but they need to be present in the same 
scope, so that the compiler can check, that what was locked 
really gets unlocked again close by (to keep it easily parsable). 
Or the block reuses the shared keyword, just to not burn another 
word for identifiers...

This is to avoid to need a cast and trusted stuff. I think shared 
and trusted should not be conflated, so that they can use a 
different review process (e.g. someone specialized in looking for 
synchronization problems)
>
> doesn't sound too compelling.