shared - i need it to be useful

Steven Schveighoffer schveiguy at gmail.com
Thu Oct 18 01:48:57 UTC 2018


On 10/17/18 6:37 PM, Manu wrote:
> On Wed, Oct 17, 2018 at 12:35 PM Steven Schveighoffer via
> Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>>
>> On 10/17/18 2:46 PM, Manu wrote:
>>> On Wed, Oct 17, 2018 at 10:30 AM Steven Schveighoffer via
>>
>>>> What the example demonstrates is that while you are trying to disallow
>>>> implicit casting of a shared pointer to an unshared pointer, you have
>>>> inadvertently allowed it by leaving behind an unshared pointer that is
>>>> the same thing.
>>>
>>> This doesn't make sense... you're showing a thread-local program.
>>> The thread owning the unshared pointer is entitled to the unshared
>>> pointer. It can make as many copies at it likes. They are all
>>> thread-local.
>>
>> It's assumed that shared int pointer can be passed to another thread,
>> right? Do I have to write a full program to demonstrate?
> 
> And that shared(int)* provides no access. No other thread with that
> pointer can do anything with it.

So then it's a misnomer -- it's not really shared, because I can't do 
anything with it.

> 
>>> There's only one owning thread, and you can't violate that without unsafe casts.
>>
>> The what is the point of shared? Like why would you share data that
>> NOBODY CAN USE?
> 
> You can call shared methods. They promise threadsafety.
> That's a small subset of the program, but that's natural; only a very
> small subset of the program is safe to be called from a shared
> context.

All I can see is that a shared method promises to be callable on shared 
or unshared data. In essence, it promises nothing.

It's the programmer who must implement the thread safety, and there 
really is no help at all from the compiler for this. At some level, 
there will be either casts, or intrinsics, both of which are unsafe 
without knowing all the context of the object. In any case, it's simply 
a false guarantee of thread safety, which might as well be a convention 
of "any function which starts with TS_ is supposed to be thread safe".

shared in the current form promises one thing and one thing only -- data 
marked as shared is actually sharable between threads, and data not 
marked as shared is actually not shared between threads. This new regime 
you are proposing does nothing extra or new, except break that guarantee.

>> At SOME POINT, shared data needs to be readable and writable. Any
>> correct system is going to dictate how that works. It's a good start to
>> make shared data unusable unless you cast. But then to make it
>> implicitly castable from unshared defeats the whole purpose.
> 
> No. No casting! This is antiquated workflow.. I'm not trying to take
> it away from you, but it's not an interesting model for the future.
> `shared` can model more than just that.
> You can call threadsafe methods. Shared methods explicitly dictate how
> the system works, and in a very clear and obvious/intuitive way.
> 
> The implicit cast makes using threadsafe objects more convenient when
> you only have one, which is extremely common.

The implicit cast means that you have to look at more than just your 
method. You have to look at the entire module, and figure out all the 
interactions, to see if the thread safe method actually is thread safe. 
That's programming by convention, and fully trusting the programmer.

I don't think this thread is going anywhere, so I'll just have to wait 
and see if someone else can explain it better. I'm a firm no on implicit 
casting from mutable to shared.

-Steve


More information about the Digitalmars-d mailing list