alvise rigo <a.rigo@xxxxxxxxxxxxxxxxxxxxxx> writes: > On Mon, Aug 3, 2015 at 6:06 PM, Alex Bennée <alex.bennee@xxxxxxxxxx> wrote: > >> >> alvise rigo <a.rigo@xxxxxxxxxxxxxxxxxxxxxx> writes: >> >> > On Mon, Aug 3, 2015 at 12:30 PM, Alex Bennée <alex.bennee@xxxxxxxxxx> >> wrote: >> >> >> >> alvise rigo <a.rigo@xxxxxxxxxxxxxxxxxxxxxx> writes: >> >> >> >>> Hi Alex, >> >>> >> >>> Nice set of tests, they are proving to be helpful. >> >>> One question below. >> >>> >> <snip> >> >>> >> >>> Why are we calling these last two instructions with the 'eq' suffix? >> >>> Shouldn't we just strex r1, r0, [sptr] and then cmp r1, #0? >> >> >> >> Possibly, my armv7 is a little rusty. I'm just looking at tweaking this >> >> test now so I'll try and clean that up. >> >> Please find the updated test attached. I've also included some new test >> modes. In theory the barrier test by itself should still fail but it >> > > Thanks, I will check them out. > > >> passes on real ARMv7 as well as TCG. I'm trying to run the test on a >> heavier core-ed ARMv7 to check. I suspect we get away with it on >> ARMv7-on-x86_64 due to the strong ordering of the x86. > > >> The "excl" and "acqrel" tests now run without issue (although again >> plain acqrel semantics shouldn't stop a race corrupting shared_value). > > > > I suppose that, in order to have some race conditions due to a lack of a > proper emulation of barriers and acqrel instructions, we need a test that > does not involve atomic instructions at all, to reduce the emulation > overhead as much as possible. > Does this sound reasonable? I'm writing a "lockless" test now which uses just barriers and a postbox style signal. But as I say I need to understand why the pure "barrier" tests still works when it really shouldn't. > > >> >> I'll tweak the v8 versions of the test tomorrow. >> >> -- >> Alex Bennée >> >> -- Alex Bennée -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html