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

Subject: Re: [boost] boost] Boost.Atomic, pushing forward and a little request for help
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-08-03 01:29:46

On Tuesday 02 August 2011 19:28:08 Phil Endecott wrote:
> Helge Bahmann wrote:
> > Hi folks,
> >
> > from the comments to Boost.Lockfree I understand that you consider a
> > non-reviewed Boost.Atomic as a "blocker"? I apologize that I have not
> > pushed forward for review (considering that "it just works for me", and
> > considering the length of the review queue...)
>
> It's not really a queue, and I believe Atomic should jump in at the front.
>
> > , but if you consider it blocking please
> > just let me know what I would need to do to clear the path.
>
> Get a review manager.
>
> > What I will do shortly is to provide and uptodate package containing
> > several fixes, several contributed by others (they are in the repo, but
> > not in any release archive) as well as some missing bits to more closely
> > match latest C++0X draft.
> >
> > The big sore point is still support for the various flavours of VC -- I
> > know that there are (especially older) versions for which it is not
> > working, but I am lacking test systems, so if you are affected please let
> > me know and I will do my best to resolve the issues.
>
> Sorry, I can't help with VC.
>
> 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 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.

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.

Best regards
Helge