shared - i need it to be useful

Steven Schveighoffer schveiguy at gmail.com
Fri Oct 19 16:43:09 UTC 2018


On 10/18/18 9:09 PM, Manu wrote:
> On Thu, Oct 18, 2018 at 5:30 PM Timon Gehr via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>>
>> On 18.10.18 23:34, Erik van Velzen wrote:
>>> If you have an object which can be used in both a thread-safe and a
>>> thread-unsafe way that's a bug or code smell.
>>
>> Then why do you not just make all members shared? Because with Manu's
>> proposal, as soon as you have a shared method, all members effectively
>> become shared.
> 
> No they don't, only facets that overlap with the shared method.
> I tried to present an example before:
> 
> struct Threadsafe
> {
>    int x;
>    Atomic!int y;
>    void foo() shared { ++y; } // <- shared interaction only affects 'y'
>    void bar() { ++x; ++y; } // <- not threadsafe, but does not violate
> foo's commitment; only interaction with 'y' has any commitment
> associated with it
>    void unrelated() { ++x; } // <- no responsibilities are transposed
> here, you can continue to do whatever you like throughout the class
> where 'y' is not concerned
> }
> 
> In practise, and in my direct experience, classes tend to have exactly
> one 'y', and either zero (pure utility), or many such 'x' members.
> Threadsafe API interacts with 'y', and the rest is just normal
> thread-local methods which interact with all members thread-locally,
> and may also interact with 'y' while not violating any threadsafety
> commitments.

I promised I wouldn't respond, I'm going to break that (obviously).

But that's because after reading this description I ACTUALLY understand 
what you are looking for.

I'm going to write a fuller post later, but I can't right now. But the 
critical thing here is, you want a system where you can divvy up a type 
into pieces you share and pieces you don't. But then you *don't* want to 
have to share only the shared pieces. You want to share the whole thing 
and be sure that it can't access your unshared pieces.

This critical requirement makes things a bit more interesting. For the 
record, the most difficult thing to reaching this understanding was that 
whenever I proposed anything, your answer was something like 'I just 
can't work with that', and when I asked why, you said 'because it's 
useless', etc. Fully explaining this point is very key to understanding 
your thinking.

To be continued...

-Steve


More information about the Digitalmars-d mailing list