On 24/08/2021 20.16, Hans Boehm via SG5 wrote:
> My attempt to draft the response to Hubert's first point, and looking back at old minutes, raised a new pair of questions:
>
> We currently require the full algorithms library, including the parallel variants, to be supported in transactions. Was that intentional? (Not a rhetorical question. I think there are arguments either way.) Note that parallel algorithms are allowed to be executed serially; they officially just add requirements to user code, making them safe to vectorize and/or parallelize.
>
> If we do require them, then this seems like a case in which a nontrivial implementation may need something like in_transaction() to avoid thread-level parallelism. But I think many simple implementations, including HTM with SGL fallback will still not need it; just falling back to a single global lock held by the main thread running the algorithm should still work, even with thread-level parallelism. So I think we should still not require it (assuming we allow parallel algorithms). Does this make sense to everybody?

I think we should simply add the parallel algorithms to the "forbidden" list.
Given that transactions are intended to be "small" and "quick", there is no
need to consider invoking an algorithm that might benefit from multi-thread
execution.

Jens