dmcq (dmcq.delete@this.fano.co.uk) on April 7, 2021 3:32 pm wrote:
> Andrey (andrey.semashev.delete@this.gmail.com) on April 7, 2021 2:32 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on April 7, 2021 1:20 pm wrote:
> > >
> > > In that situation, a transaction that is bigger than the architected hardware resources would
> > > not be an "abort" - it would just be a fatal error, like a divide-by-zero is, and would trap.
> > > It would be very expensive indeed, but that would be ok - because there would be no "retry with
> > > fallback" for that case. It would have been a programmer error to have generated such an instruction
> > > sequence in the first place, exactly like it's a programmer error to divide by zero.
> >
> > Except that the programmer doesn't generate instructions
> > usually. Unlike divide by zero, the programmer cannot
> > ensure that a particular sequence of instructions is generated, unless he writes in assembler. And I doubt
> > a technology that basically requires writing in assembler is going to succeed beyond a few niche cases.
>
> I think it should be possible to gve some minimum figures for what is supported and run a computer
> check. If some mplementations provide more then they would be warned that they use more than some
> standard. It woud be much simpler than saying what a GPU supports. I don't think assembler would
> need to be used and assembler would only be for specific important optimisations.

Thing is, I don't see the point in defining the limit on the transaction size to begin with. HTM implementation has no reason to care about instruction count, the only thing it should care about is memory accesses. Larger transactions will abort more often by nature, so there's already an implicit practical upper limit.

> > Well, the incremental approach is certainly reasonable. But whatever small starting solution you implement,
> > you still have to make sure it is generally useful. If it requires a domain expert level programmers or
> > isn't usable in higher level languages or doesn't support widespread use cases then - however nice and
> > simple it is - it will be just a toy technology with no wide use, and therefore not worth the cost and
> > effort of implementing. You have to start with something more widely applicable and useful.
>
> This whole area requires good programmers and well checked code. Atomics and locks require some care anyway
> and everyone should think twice, three or more times before coming anywhere near lock free code.

Any reasonably educated programmer is able to use a mutex. Most are able to use a condition variable. One may not be an expert in concurrency programming, but still be able to write working, though possibly not state of the art multithreaded code. The bar is higher for atomics, but most programmers should be able to implement a simple reference counter.

I'm not saying HTM programming must be as simple and accepting, but it should certainly not require one to be an expert to get even the minimal result. It should be compatible with current programming practices or at least be relatively easily adoptible. Certainly, it should not require one to write in asm and be acquainted with specifics like instruction counts.