On 18 September 2012 18:39, Binyamin Dissen <[email protected]> wrote:
> From my read of the doc it appears that TS only serializes with other code > equally doing TS. I don't see how non-TS code running a linked-list is > protected if the TS code removes an item from the list. I don't think there is any serialization going on; avoiding it is the whole point. I don't think the TS code is able to remove an item if there is a fetch or store conflict (essentially if the same cache line is referenced by the TS and any other code, TS or not). The TS code will be aborted, and its changes backed out (or never made, depending on your preferred but unverifiable view of how things *really* work). And clearly, the CPU's estimate of whether there was a conflict will be safe, that is it may report potential conflicts that are not real, but will never fail to report an actual one. But certainly it is not a magic "no serialization needed" trick; for instance a queue header far away from an element will not be protected. > So instead of running a chain using PLO compare-and-fetch I can now use TS to > do the same function. But code that is not aware is not protected. I'm not so sure. What surprises me most about this new facility is that it does detect fetches and stores done by I/O operations. That must surely be slow and difficult to implement, and to what useful purpose? The only thing I can think of is the new Flash PCIe cards, but I don't know if those are I/O devices in the traditional model, or are accessed by some other mechanism. Tony H.
