Boost logo

Boost :

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-06 10:35:18


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.

http://www.1024cores.net/home/relacy-race-detector

Interesting. Have you used it? Is it really useful for testing the
atomic implementation, rather than testing application code that is
built on top of it?

I once tried to use Helgrind, which is a Valgrind race-detection tool.
I didn't get very far.

Regards, Phil.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk