On Thu, Apr 12, 2012 at 12:38:44AM +0200, Torvald Riegel wrote: > On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote: > > > Tests passing, bootstrap in progress. > > > > > > Comments? > > > > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't > > see that in the code. I think that's really required, otherwise the > > optimizer > > will do the wrong thing and move memory references outside the region. > > Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START / > HLE_END instead? Not particularly great names, but at least it avoids > overloading ACQUIRE/RELEASE and thus should make it clearer that you > still need to specify a memory order.
It still seems wrong to me. HLE is an x86 construct, so weaker memory orders on the compiler level than what the instruction implements does not really make sense to me. And the instruction just has LOCK semantics. Currently it's highly error prone -- on the Russel hard to misuse scale not higher than 1 as is  At the minimum it would need a warning with RELAXED as suggested by Jakub earlier. > I agree with Jakub that users really should specify memory order bits, > if they want ordering. Andi, I also see your point regarding catching > bugs, but this is really expert stuff, and my hope is that we can make > HLE really transparent or at least provide better abstractions around it At least this form of HLE cannot be transparent, it has to be annotated by the programmer. -Andi  http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html -- a...@linux.intel.com -- Speaking for myself only.