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@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
