Transactional memory in the dentry cache

Posted Oct 4, 2013 10:32 UTC (Fri) by nix (subscriber, #2304)
In reply to: Transactional memory in the dentry cache by mathstuf
Parent article: Transactional memory in the dentry cache

Not if using it there trips up glibc because glibc cannot tell that the transaction that just aborted was not one it started, but one started by the Haskell implementation.

Transactional memory in the dentry cache

Posted Oct 4, 2013 10:51 UTC (Fri) by andresfreund (subscriber, #69562) [Link] (4 responses)

Trying to use TSX across another set of locks sounds like inviting trouble. But anyway, I think TSX supports nested transactions, although I don't really know enough about the semantics defined for that.

Transactional memory in the dentry cache

Posted Oct 7, 2013 7:15 UTC (Mon) by johill (subscriber, #25196) [Link] (1 responses)

I believe nesting is supported in the ISA but really just aborts all the time (in the current implementation.)

Transactional memory in the dentry cache

Posted Oct 7, 2013 10:09 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

From what I gather, even on Haswell, the nested transaction just is combined with the outer one. I.e. the commit of the inner transaction is basically ignored and only the outer commit has an actual meaning. A rollback in the nested transaction rolls back to the toplevel abort point.

Transactional memory in the dentry cache

Posted Oct 7, 2013 20:54 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

Trying to use TSX across another set of locks sounds like inviting trouble.

I agree. But, of course, that's not that obvious. You don't use those locks in glibc by calling a do_a_tsx_lock() function: it's done behind your back by the pthreads locking code, and you can't rely on that being the only place it's done without tying yourself to an internal implementation detail of glibc...

Transactional memory in the dentry cache

Posted Oct 7, 2013 20:59 UTC (Mon) by andresfreund (subscriber, #69562) [Link]

>> Trying to use TSX across another set of locks sounds like inviting trouble.

> I agree. But, of course, that's not that obvious. You don't use those locks in glibc by calling a do_a_tsx_lock() function: it's done behind your back by the pthreads locking code, and you can't rely on that being the only place it's done without tying yourself to an internal implementation detail of glibc...

I think using TSX across *any* kind of lock is asking for trouble. And pthreads locking certainly is a kind of locking ;). There are some places where glibc uses locks internally that aren't immediately obvious, but those aren't ones that you'd likely use inside TSX either.