Scientific computing and parallel computing C++23/C++26

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jan 13 21:44:13 UTC 2022


On Thu, Jan 13, 2022 at 09:13:11PM +0000, jmh530 via Digitalmars-d wrote:
> On Thursday, 13 January 2022 at 20:58:25 UTC, H. S. Teoh wrote:
[...]
> > I'm not 100% sure why .parallel is @system, but I suspect it's
> > because of potential issues with race conditions, since it does not
> > prevent you from writing to the same local variable from multiple
> > threads. If pointers are updated this way, it could lead to memory
> > corruption problems.
[...]
> Could it be made @safe when used with const/immutable variables?

Apparently not, as Petar already pointed out.

But even besides access to non-shared local variables, there's also the
long-standing issue that a function that receives a delegate cannot have
stricter attributes than the delegate itself, i.e.:

	// NG: @safe function fun cannot call @system delegate dg.
	void fun(scope void delegate() @system dg) @safe {
		dg();
	}

	// You have to do this instead (i.e., delegate must be
	// restricted to be @safe):
	void fun(scope void delegate() @safe dg) @safe {
		dg();
	}

There's currently no way to express that the @safety of fun depends
solely on the @safety of dg, such that if you pass in a @safe delegate,
then fun should be regarded as @safe and allowed to be called from @safe
code.

This is a problem because .parallel is implemented using .opApply, which
takes a delegate argument. It accepts an unqualified delegate in order
to be usable with both @system and @safe delegates. But this
unfortunately means it must be @system, and therefore uncallable from
@safe code.

Various proposals to fix this has been brought up before, but Walter
either doesn't fully understand the issue, or else has some reasons he's
not happy with the proposed solutions.  In fact he has proposed
something that goes the *opposite* way to what should be done in order
to address this problem.  Since both were shot down in the forum
discussions, we're stuck at the current stalemate. :-(


T

-- 
Once bitten, twice cry...


More information about the Digitalmars-d mailing list