Shared - Another Thread

Dominikus Dittes Scherkl dominikus at scherkl.de
Fri Oct 19 23:40:44 UTC 2018


On Friday, 19 October 2018 at 18:11:50 UTC, Manu wrote:
> On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via 
> Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>>
>> On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
>> > [...] What issues am I failing to address?
>> [...] Another point is the part of "how can the compiler 
>> support the expert in writing threadsave methods" - which you 
>> answered with "not a little bit at the moment, but we may 
>> improve this in the future" - and that is not at all 
>> satisfying.
>
> I think you've misunderstood.
> My proposal is @safe... if you stay @safe, you will receive 
> guarantee that your code is threadsafe.
On user side, yes.
> If you want to implement a low-level device, you must implement 
> a @trusted function, and I don't know what the compiler can do 
> to help you.
Yes, but that's seldom. More often the "expert" will write new 
shared types using the low level trusted functions like anybody 
else. But that
still requires special care - he has to consider tread-safety in 
every
method of a new type, even the non-shared ones. And he has to 
fill any
possible gap like construction and assignment so that the 
end-user is really sure to not accidentally misusing the type!
And I think a serious proposal need to address this - I think the 
compiler could really help here (e.g. prescribe what operators 
need to be overloaded and check that all methods use the proper 
mechanisms to lock the shared members before operating on them 
etc.)

> So saying that my response that "there is @trusted code at the 
> bottom of the stack" is not satisfying is really just a comment 
> on your opinion about @trusted code in general.
That just comes on top of it.

> My proposal is designed to be useful and @safe for *users* as 
> primary goal.
I agree with you, but others seem not so convinced (yet?).
[...]
> The user has manually cast to unshared inside their 
> unsafe/(@trusted?) function, what more signal do they need that 
> they've engaged in an unsafe operation?
Some hints what to do to be able to trust them?
You asked what issues you were failing to address. That was just 
some ideas of mine what you may address in addition.


More information about the Digitalmars-d mailing list