shared - i need it to be useful

[Manu]

On Mon, Oct 22, 2018 at 6:40 AM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 22.10.18 03:01, Manu wrote:
> > Where did I ever say anything like that? I'm sure I've never said
> > this.
>
> ???
>
> I said that you are proposing to allow implicit conversions to shared
> for all classes, not only core.atomic.Atomic, and the last time you said
> it was the previous sentence of the same post.

Sorry, I read the "not proposing to let" as something like "proposing
to not let".
So let me re-respond.

Yes, I propose implicit conversion to shared. That's what makes it usable.
Basically any argument to a fork/join, parallel-for, map/reduce,
etc... they all require this transition.
Our software is almost exclusively made up of those processes. Almost
every type we have transits to shared contexts (with a restricted
threadsafe API), and almost nothing we have could be allocated shared
to the exclusion of thread-local access (like Atila likes to suggest).
I don't know how to make use of the mutually-exclusive design of the
current model in any code I've ever written.

I've been writing SMP code since the xbox360 alpha-kit landed on my
desk in 2006. As we've matured, we've seen mutexes disappear
completely. Even discreet worker threads which used to use semaphores
to signal new work arrival are dispappearing as it's becoming
impossible to find enough distinct kinds of work for a discreet worker
threads to do that keeps all cores busy.
We break the work into tasks, build a DAG of the execution schedule
with respect to data access dependencies, and parallel-for/reduce
within tasks that operate over large volumes of data.
We used to hide data sharing detail behind walls, but it moves into
user-facing code as parallel-for appears, and that invokes the
necessity to be able to express what is threadsafe at the type system
level.

I can assure, in our architecture at least, I am not aware of any case
where a user would write a @trusted function under my proposal. We
could run our stack @safe.

> >>> You seem to be stuck on the detail whether you can trust the @trusted
> >>> author though...
> >>
> >> Again: the @safe author is the problem.
> >
> > I don't follow. The @safe author is incapable of doing threadsafety
> > violation.
>
> They are capable of doing so as soon as you provide them a @trusted
> function that treats data as shared that they can access as unshared.

That function is not @trusted by definition.

> > They can only combine threadsafe functions.
> > They can certainly produce a program that doesn't work, and they are
> > capable of ordering issues, but that's not the same as data-race
> > related crash bugs.
>
> Accessing private members of aggregates in the same module is @safe.
> tupleof is @safe too.

I don't see any situation where any user would write code in the same
module as core.atomic, or core.mutex, or wherever these couple of
functions live.