On Mon, Oct 15, 2018 at 12:15 PM Peter Alexander via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote: > > 2. object may have shared methods; such methods CAN be called on > > shared instances. such methods may internally implement > > synchronisation to perform their function. perhaps methods of a > > lock-free queue structure for instance, or operator overloads on > > `Atomic!int`, etc. > > Just checking my understanding: are you saying here that shared > methods can effectively do anything and the burden of correctness > is on the author? Or do you still have to cast the shared away > first?
Burden of correctness that a `shared` method is indeed threadsafe is absolutely on the author; there's nothing we can do to guarantee this (multithreading is hard!), but in this new world, a user of an API will be able to see shared methods and assume that they're threadsafe, since that would be (and should be!) the whole point. Since `shared` has no read or write access, at the bottom of the stack, it may be necessary that the function cast shared away to implement its magic. If you lock a mutex for instance, then you naturally need to cast it away; but that's solving the problem with a sledge-hammer. In my experience, most such functions are implemented with atomics; and the atomic API already receives shared args, ie: https://github.com/dlang/druntime/blob/master/src/core/atomic.d#L379 So, if you do your work with atomics, then you don't need any casts. Also, if the object is a composite, then a `shared` method is able to call `shared` methods on its members, and in that case, you are able to do useful aggregate work without casting. I think the interactions I describe above are all correct.
