DIP 1024--Shared Atomics--Community Review Round 1

[Ola Fosheim Grøstad]

On Saturday, 12 October 2019 at 09:45:41 UTC, Jonathan M Davis 
wrote:
> It's the same as with any @trusted code. It's up to the 
> programmer to ensure that what the code is doing is actually 
> @safe, and if the code isn't able to provide an API that is 
> @safe, then it shouldn't be @trusted.

So, I am trying to figure out what that API would have to look 
like and the only solution I can think of right away is that you 
have are doing a callback back into @safe code from the 
lock-holding @trusted code?

So, if you have to obtain locks from multiple sources, it either 
won't work out, or you have to use some serious kludges, like a 
deep call chain:

while(tryagain) {
     trusted_code_obtains_lock_1-->
        safe_code_callback1 calls->
            trusted_code_obtains_lock2
                safe_code_callback2 processes and sets 
tryagain=false
}

Of course, that could lead to starvation.

So to avoid all of that multi-threaded libraries have to have 2 
APIs, one simple transactional wrapper-API for @safe code and 
another API for @trusted code that can be used to write a new 
wrapper that allows locking of multiple datastructures.

I hope people try to sketch out what such libraries will look 
like before the semantics are decided on. Maybe an experimental 
branch would be appropriate.