shared - i need it to be useful

Manu turkeyman at gmail.com
Mon Oct 15 23:57:01 UTC 2018


On Mon, Oct 15, 2018 at 4:25 PM Peter Alexander via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Monday, 15 October 2018 at 20:53:32 UTC, Manu wrote:
> > On Mon, Oct 15, 2018 at 1:05 PM Peter Alexander via
> > Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> >>
> >> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> >> 1. A single producer, single consumer (SPSC) queue is
> >> necessarily shared, but is only safe if there is one writing
> >> thread and one reading thread. Is it ok if shared also
> >> requires user discipline and/or runtime checks to ensure
> >> correct usage?
> >
> > I think you can model this differently... perhaps rather than a
> > single
> > object, it's a coupled pair.
>
> That's a nice design.
>
>
> > Your swap function is plain broken; it doesn't do what the API
> > promises.
> > You can write all sorts of broken code, and this is a good
> > example of
> > just plain broken code.
>
> If it is broken then why allow it? Why do we need to cast shared
> away if they weren't atomic and why do we allow it if they are
> atomic?

It's not that it's 'allowed' other than, yes, access to atomic int's
is allowed in a threadsafe way because atomic access to individual
int's is threadsafe, so the primitive operation is perfectly
acceptable.

Your function models a higher-level concept; which is an atomic swap.
You need to make sure that a threadsafe API you're authoring does
actually deliver on the promise it makes.

> I understand that shared can't magically tell you when code is
> thread safe or not. It does make sense to disallow almost
> everything and require casts. I'm just not seeing the value of
> allowing shared methods to access shared members if it isn't
> thread safe. Make it require casts.

Because in an awful lot of cases, it is threadsafe. Implementing
low-level machinery, and consuming such machinery should have a 1:many
relationship. You're talking about adding friction to the 'many' such
that the '1' knows that they need to implement their function right? I
mean, they already know that, because they wrote 'shared' after their
function declaration.

In the common case, perhaps my object might aggregate a threadsafe
queue, and my shared method prepares an item and then adds it to the
queue. I think the vast majority case will be making use of utility
functionality and that shouldn't present undue friction.
It's not like atomic int's that are class members are going to be
accidentally twiddled; you added Atomic!int's to your class, and that
wasn't an accident... and if you're making use of the lowest-level
atomic primitives, it's fair to presume you know how to use them.
You're writing a shared method, which means you already encapsulate
the promise that you are implementing a function that deals with
thread-safety. I don't know what the cast in this case would add.


More information about the Digitalmars-d mailing list