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

[Petar]

On Thursday, 13 January 2022 at 21:13:11 UTC, jmh530 wrote:
> On Thursday, 13 January 2022 at 20:58:25 UTC, H. S. Teoh wrote:
>> [snip]
>>
>> 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.
>>
>>
>> T
>
> Could it be made @safe when used with const/immutable variables?

For some data to be @safe-ly accessible across threads it must 
have no "unshared aliasing", meaning that `shared(const(T))` and 
`immutable(T)` are ok, but simply `T` and `const(T)` are not.

The reason why the `.parallel` example above was not safe, is 
because the body of the foreach was passed as a delegate to the 
`ParallelForeach.opApply` and the problem is that delegates can 
access unshared mutable data through their closure. If the 
@safe-ty holes regarding delegates are closed, presumably we 
could add a `ParallelForeach.opApply` overload that took a 
`@safe` delegate and then the whole `main` function could be 
marked as `@safe`.

I think back when the module was under active development, the 
authors did carefully consider the @safe-ty aspects, as they have 
written code that conditionally enables some function overloads 
to be `@trusted`, depending on the parameters they receive. But 
in the end it was the best they could given the state of the 
language at the time. Most likely the situation has improved 
sufficiently that more the of the API could be made (at least 
conditionally) @safe.

You can check the various comments explaining the situation:

* 
https://github.com/dlang/phobos/blob/v2.098.1/std/parallelism.d#L32-L34
* 
https://github.com/dlang/phobos/blob/v2.098.1/std/parallelism.d#L3382-L3395
* 
https://github.com/dlang/phobos/blob/v2.098.1/std/parallelism.d#L254-L261