Re: [boost] Boost.Atomic, pushing forward and a little request for help

Subject: Re: [boost] Boost.Atomic, pushing forward and a little request for help
From: Matt Chambers (matt.chambers42_at_[hidden])
Date: 2011-08-07 17:55:48

On Aug 7, 2011 1:41 PM, "Helge Bahmann" <hcb_at_[hidden]> wrote:
>
>
>
> On Saturday 06 August 2011 07:40:02 Gottlob Frege wrote:
> > On Wed, Aug 3, 2011 at 11:52 AM, Phil Endecott
> >
> > <spam_from_boost_dev_at_[hidden]> wrote:
> > > Helge Bahmann wrote:
> > >> On Tuesday 02 August 2011 19:28:08 Phil Endecott wrote:
> > >>> The thing that I believe is missing is tests.  Do you have any
thoughts
> > >>> about that?
> > >>
> > >> Well, I have a few simple tests for atomicity only, they are
hand-built
> > >> and I am working to push them into the boost build system.
> > >>
> > >> I don't know how useful the tests are though -- while on a true SMP
> > >> platform (ppc and x86 being available to me) they manage to fail
quite
> > >> realibly if I intentionally break something (like removing "lock"
> > >> prefixes, or replacing stwcx. with an unconditional store), but it
takes
> > >> ages (if it works at all) to produce test failures on non-SMP (all
> > >> threads to the same CPU).
> > >
> > > I recall someone once increasing the kernel's scheduling frequency to
> > > make this work better.  On Linux, I think this means changing HZ and
> > > recompiling the kernel.  Perhaps there is some trick that could be
used
> > > to force the kernel to reschedule more frequently without going to
those
> > > lengths.  Or maybe it is easier on some other platform.
> > >
> > > Even so, scheduling only happens between instructions, not between
memory
> > > accesses.  When a single instruction does more than one memory access
> > > (i.e. a typical CISC instruction), process scheduling will never occur
> > > between the two memory accesses.
> >
> > Maybe we should look at using Relacy (google for it) for tests.
>
> It is only able to aid in exercising things that use the atomic interface,
not
> the implementation itself.

How will c++1x implementors test it?