On Mon, Oct 15, 2018 at 5:10 PM Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Monday, 15 October 2018 at 23:30:43 UTC, Stanislav Blinov > wrote: > > On Monday, 15 October 2018 at 21:51:43 UTC, Manu wrote: > > > >> I see it this way: > >> If your object has shared methods, then it is distinctly and > >> *deliberately* involved in thread-safety. You have deliberately > >> opted-in to writing a thread-safe object, and you must deliver > >> on your promise. > >> > >> The un-shared API of an object that supports `shared` are not > >> exempt from the thread-safety commitment, they are simply the > >> subset of the API that may not be called from a shared context. > > > > And therefore they lack any synchronization. So I don't see how > > they *can* be "compatible" with `shared` methods. > > > > I think Manu means you have a shared object with some shared > methods and some unshared methods. The shared methods deal with > synchronisation and can therefore be call from anywhere by > anyone, whereas the unshared methods must be called on a locked > object.
Yes, except maybe I didn't make it clear that I DO expect the un-shared methods to be aware that a sibling shared method does exist (you wrote it!), and that it may manipulate some state, so *if* the un-shared method does interact with the same data that the shared method may manipulate (in many cases, it won't; it's likely only a small subset of an object's functionality that may have thread-safe access), then the un-shared method does need to acknowledge that functional overlap. So even though a method is un-shared, it still needs to be aware that it may have sibling methods that are shared. If they don't access an overlapping data-set, no special handling is required. If they do overlap, they may need to coordinate appropriately.