shared - i need it to be useful

[Manu]

On Mon, Oct 15, 2018 at 5:10 PM Nicholas Wilson via Digitalmars-d
<digitalmars-d at 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.