Date: Tue, 24 Aug 2021 11:16:56 -0700
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?
Hans
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?
Hans
Received on 2021-08-24 13:17:09