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: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2011-08-03 11:52:54

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.

I think it is probably safe to test only on multi-core systems, and to 
assume that if code works on them then it will also work on single-core systems.

> I have not yet looked into writing something for memory ordering tests, but 
> arguably that's both even more important and more difficult to reproduce 
> failures.

I agree.  I have no idea where to start on that.  Hopefully there is 
someone else reading with a clue....

> The other aspect that I want to provide is compile-time test for API 
> completeness. I suspect there are a few small things missing still.

Yes.  Also, it would be very easy to make a copy&paste error and find 
that something is doing an atomic add instead of an atomic and.  Or 
that it was only changing the least-significant byte, or something.  So 
some basic "does everything compile (and assemble)?" and "do I get the 
same answer as with non-atomics?" tests would be good.

Also, I think it would be useful to verify at compile time that the 
expected atomic code is being used, and not the fallback (this is 
something that has bitten me).  In fact, it might be worth putting in a 
#warning for the fallback implementation that the user has to 
explicitly disable.

Regards,  Phil.