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

Manu turkeyman at gmail.com
Sat Oct 12 23:36:55 UTC 2019

On Sat, Oct 12, 2019 at 4:30 AM Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

Here's a rough draft of one such sort of tool I use all the time in
shared-intensive code:

I just hacked that together the other night to do some experiments. I
have a toolbox like that which we use at work.
This code here feels fine to me in D, but it all depends on
restrictive shared to work.
There's nothing useful you can do with shared safely as it exists in
the language today.

More information about the Digitalmars-d mailing list