Branch prediction across memory barriers is also something I don’t think is doable.
My understanding is weak, but this doesn't sound right. Presuming he means that "speculative execution across a write memory barrier is prohibited", is he correct?
My understanding is weak, but this doesn't sound right. Presuming he means that "speculative execution across a write memory barrier is prohibited", is he correct?
Transactional memory is useful for using a coarse lock to access a wide set of data most of which is not accessed concurrently. You are having the hardware doing the work of lock elision/splitting for you.
This saves you from having the unnecessary mutual exclusion of a regular coarse lock. Or alternatively it saves you from the unnatural acts necessary to get lock splitting or eliminate shared state.
For write mostly counters where performance is an issue you want to have a thread local counters or striped counters.
See http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr1... for an example of how that is done. This counter demonstrates lock splitting as well as an attempt at mechanical sympathy by trying to pick the right stripe based on CAS failures.
>It creates a “memory barrier” CPU are usually free to >shuffle around the stream of instructions that flow through >them and it is done all the time as the CPU constantly >optimizes the instruction stream to keep all its resources >busy. A lock creates a barrier and the CPU is not allowed >to move stuff past this barrier. Branch prediction across >memory barriers is also something I don’t think is doable.
He's confusing instruction retiring with memory ordering. On modern fast CPUs they are only vaguely related.
>Cache coherency. The address line that stores the lock gets >invalidated and the content in that cache gets thrown out.
That's not how a modern CPU with MESI protocol operate. As long as the cache line stays EXCLUSIVE to that core it does not get invalidated.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
So nothing that occurs inside a LOCK and UNLOCK operation will be re-ordered, but things that exist outside these LOCK and UNLOCK operations may be re-ordered in such a way that it appears that something before the LOCK statement actually occurred after it.
I think.
My point is just that the linux doc illustrates the minimum guarantees for how Linux approaches these issues, which given a ACQUIRE/RELEASE instruction in x86 and load/store ordering, is probably going to be pretty accurate for the state of successful lock execution behavior in the more general sense.
being a tad pedantic here, but shouldn't this be a part of the machine's micro-arch rather than the isa ?
I was talking about how lock worked in linux, which could be implemented using lock+addl, or xchg, etc. The TSX HLE stuff (xacquire/xrelease) are precisely what that document doesn't cover.
So it's a bit convoluted. I was talking about micro-arch + linux implementation, and how it invalidates TFA's assumption of speculative execution. The documentation talks about micro-arch, but could be mistaken for discussing the ISA.
So you're right, the article is discussing the micro-arch(and the ISA inherently due to TSX), and the document I posted is only talking about micro-arch, but could be mistaken for ISA stuff (as per a private email I had with someone about the word LOCK)