|
From: Eliot M. <mo...@cs...> - 2012-02-21 14:40:32
|
Dear developers -- Recently Intel announced that some future processor, probably to be released next year, will support instructions related to transactional memory. As one of the originators of the transactional memory idea, I am thrilled by this, of course. I am also intrigued by the possibility of adding support for these instructions to valgrind. Intel calls these Transactional Synchronization Extensions (TSE). Here is a good place to start reading about them, if you're interested: http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell/ Chapter 8 of this manual gives details: http://software.intel.com/file/41604 It includes two new prefixes, XACQUIRE and XRELEASE, which mark locks that can be elided transactionally, and three new instructions, XBEGIN, XEND, and XABORT, which support "Restricted Transactional Memory" (RTM). There is also XTEST, which tests whether execution is currently during a transaction. The prefixes, encoded as 0xF2 and 0xF3 are ignored by other processors, and I suppose *could* be ignored by valgrind as well. We'd have to see what makes the most sense. XBEGIN/XEND and friends are more interesting. If certain instruction occur during a transaction, the transaction will *always* abort, which means its memory writes since XBEGIN must disappear, and execution must continue with an alternate path. The *simplest* (but least useful, IMO) implementation in valgrind would immediately go to the alternate path, indicating that it will no succeed on retry. (In RTM, transactional "blocks" must always provide an alternate code path, perhaps one using ordinary locks.) More interesting implementations would add support for rollback, at the least. It is such implementations that would interest me most, and on which I would be quite willing to collaborate. Doing this well requires some thought and possibly some subtle surgery on valgrind, so I would not undertake it without a degree of collaboration from one or more experienced valgrind developers. You might be thinking "There's no hurry, these chips won't be out there for a while," but actually, getting a functional simulator available for people to use could be a great service in advance of actual hardware being available. So, let me know what you think, and if there is some interest, I can describe my implementation strategy ideas in more detail for you to critique. Regards -- Eliot Moss |