On Mon, Oct 30, 2006 at 01:28:04AM -0700, Justin Erenkrantz wrote: > On 10/30/06, Colin Hirsch <[EMAIL PROTECTED]> wrote: > >> The both use 'mfence' on AMD64. The AMD x86-64 manual: > >> > >http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24594.pdf > >> > >> 'mfence' is on page 182 of Vol 3: > > > >Aha, so we need a memory barrier on x86-64 too? The implementation > >currently > >seems to assume that the same rule as for x86-32 applies, namely that the > >architecture is NOT weakly ordered? > > I don't profess to know. But, AFAICT, both Intel and AMD CPUs support > the MFENCE op when in x86-64 mode.
Ok, perhaps we'll leave Intel/AMD for later... ;-) > >I haven't checked testatomic in depth, but it seems to test that the > >individual operations work correctly, but not whether all combinations > >of operations work correctly, otherwise it would have already found the > >issues that the patch tries to fix. The problem is of course that it is > >not so easy to test all operations, and all _combinations_, in a way > >that really breaks if there is a problem with the synchronisation... > > Can we at least have it test the issues that this patch tries to fix? > Are they easily reproducable? Hm ... to trigger the bug in apr_atomic_inc32 without waiting for hours one would need at least two CPUs, each performing an apr_atomic_inc32 in a tight loop; one would then need to save all return values, and check whether every number occurs only once. Of course this test is still not 100% deterministic... To make it work reasonably well one would need to have large arrays for the return values, one per thread, all pages touched by memset; and as simultaneous a start of the threads as possible, probably via a broadcast on a condition variable. Any simpler ideas? Regards, Colin
