C++ Logo

sg5

Advanced search

Re: [SG5] in_transaction()

From: Hans Boehm <boehm_at_[hidden]>
Date: Tue, 24 Aug 2021 13:57:09 -0700
I'm entirely fine with that.

The down side is of course that you might be invoking an inner product
function on a 3 element vector, and it uses parallel unsequenced algorithms
underneath because it's designed to work for a billion elements as
well, and expects the implementation to ignore that for three elements. But
I agree that it's more important for now to not require implementers to
deal with that.

Hans

On Tue, Aug 24, 2021 at 12:55 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:

> 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
>
>

Received on 2021-08-24 15:57:24