Scientific computing and parallel computing C++23/C++26
Thu Jan 13 21:51:10 UTC 2022
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:
>> 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?
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
You can check the various comments explaining the situation:
More information about the Digitalmars-d