By: Aspect of Anonimity (aoa.delete@this.hjiffdhkoouggkl.com), April 6, 2021 3:20 pm
Room: Moderated Discussions
sr (nobody.delete@this.nowhere.com) on April 6, 2021 7:12 am wrote:
> Aspect of Anonimity (aoa.delete@this.ddugjjihjvj.com) on April 5, 2021 7:57 pm wrote:
> > As I say in my previous comment to sr: even in theory TM instructions that can fail are terrible (if
> > I was unclear, see anon above). I attempted to end with the question "why bother with TM?", but I guess
> > it came off as a rebuke and I got no reply. I stopped caring for an answer at this point anyway...
> >
> > So lets forget practice and current TM and lets try to come up with a "nice" theoretical
> > TM feature, one that never aborts. If that's infeasable then forget TM forever.
>
> Why so afraid of aborts? Your CPU speculate and aborts all
> the time, TM just expands that feature to coherent memory.
>
My cpu does not ask me what to do every time it aborts...
> Transactional memory solves about one problem - offer atomic memory operations to coherent shared memory.
Lets call this problem X.
> And problem is that doing atomic memory operations to coherent memory you have to lock every cache line you
> modified from other cores and only release them when all memory operations are done. All fine as long as
This is solution A.
> there's only one thread, even uniprocessor system gets problems with additional threads - two threads are
Threads T1 and T2.
> locked parts of memory and their processing needs cache line that is locked in other thread - a deadlock.
But locking can also NOT deadlock!
But ok, solution A bad.
Let TM be solution B.
>
> In TM-capable cpu hardware resolves that deadlock by canceling at least one of those conflicting
T1 uses B to solve X.
T2 uses B to solve X.
B aborts for T1.
T2 solved X with B.
B good, T2 happy.
T1 wants to solve X.
T1 must use A.
A bad, T1 sad,
OR
T1 solved X with A.
T1 "fu B!".
T1 joined the dark side.
> threads. TM hardware can also prevent that deadlock with interlocking those two threads, so
> threads can share their speculative work - but that probably isn't implemented in hardware yet.
> TM as now as considered as "best effort" - they implement features that they can easily to existing
> designs, there's lots of unimplemented possibilities to improve performance.
>
> And traditional software version to do atomic memory operations to coherent memory is to lock memory
> regions - and that sucks, firstly by that it's not protected by hardware. And because of that it
> makes multithreading so complicated that almost nobody can do it to anything but the most simplest
> things. Any real problems needs to rely on third-party locking libraries and so on.
Keeping it simple is the only way to avoid the halting problem, or lots of sweat and tears.
> Aspect of Anonimity (aoa.delete@this.ddugjjihjvj.com) on April 5, 2021 7:57 pm wrote:
> > As I say in my previous comment to sr: even in theory TM instructions that can fail are terrible (if
> > I was unclear, see anon above). I attempted to end with the question "why bother with TM?", but I guess
> > it came off as a rebuke and I got no reply. I stopped caring for an answer at this point anyway...
> >
> > So lets forget practice and current TM and lets try to come up with a "nice" theoretical
> > TM feature, one that never aborts. If that's infeasable then forget TM forever.
>
> Why so afraid of aborts? Your CPU speculate and aborts all
> the time, TM just expands that feature to coherent memory.
>
My cpu does not ask me what to do every time it aborts...
> Transactional memory solves about one problem - offer atomic memory operations to coherent shared memory.
Lets call this problem X.
> And problem is that doing atomic memory operations to coherent memory you have to lock every cache line you
> modified from other cores and only release them when all memory operations are done. All fine as long as
This is solution A.
> there's only one thread, even uniprocessor system gets problems with additional threads - two threads are
Threads T1 and T2.
> locked parts of memory and their processing needs cache line that is locked in other thread - a deadlock.
But locking can also NOT deadlock!
But ok, solution A bad.
Let TM be solution B.
>
> In TM-capable cpu hardware resolves that deadlock by canceling at least one of those conflicting
T1 uses B to solve X.
T2 uses B to solve X.
B aborts for T1.
T2 solved X with B.
B good, T2 happy.
T1 wants to solve X.
T1 must use A.
A bad, T1 sad,
OR
T1 solved X with A.
T1 "fu B!".
T1 joined the dark side.
> threads. TM hardware can also prevent that deadlock with interlocking those two threads, so
> threads can share their speculative work - but that probably isn't implemented in hardware yet.
> TM as now as considered as "best effort" - they implement features that they can easily to existing
> designs, there's lots of unimplemented possibilities to improve performance.
>
> And traditional software version to do atomic memory operations to coherent memory is to lock memory
> regions - and that sucks, firstly by that it's not protected by hardware. And because of that it
> makes multithreading so complicated that almost nobody can do it to anything but the most simplest
> things. Any real problems needs to rely on third-party locking libraries and so on.
Keeping it simple is the only way to avoid the halting problem, or lots of sweat and tears.
