Subject: Re: [boost] Notice: Boost.Atomic (atomic operations library)
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-12-03 18:53:33
Helge Bahmann wrote:
> Hi Phil,
> Am Thursday 03 December 2009 15:58:03 schrieb Phil Endecott:
>> Helge Bahmann wrote:
>> > I will shortly be adding a small howto on adding platform support to the
>> > library.
>> Please let me know when this is ready. I currently have a bit of time
>> to spend on this.
> There is one planned internal API change (switching to the four-parameter
> compare_exchange_*) still pending, but that should be straight-forward
> afterwards. If you want to try, I have started writing things up, the current
> state is at:
Thanks, just what I need.
> (the tarball also contains the generated docs, still busy reworking to use
>> In summary, the cases that I need to handle are:
>> 1. Linux kernel provided memory-barrier and CAS operations (only);
> does any of these arm platforms (this is pre-v6 probably?) actually support
> smp? if not, then the barriers will probably be NOPs
I think the barrier is a DMB instruction, but in principle the kernel
could put nothing there on uniprocessors. There's still the small
overhead of the call, which we could consider omitting if we were
certain that it was a uniprocessor.
Anyway, in this case I think I need to implement load, store and
compare_exchange_weak using the kernel-provided functions and add your
__build_atomic_from_minimal and __build_atomic_from_larger_type on top.
(BTW, why do you use leading __s ? I was under the impression that
such identifiers were reserved.)
>> 2. Asm load-locked/store-conditional for words (only);
>> 3. As 2 but also for smaller types.
> sounds like this is going to be one of the most complicated platforms, so I
> really appreciate your experience here...
Would it be possible to add another set of builders that could use
load-locked and store-conditional functions from a lower layer? This
could reduce the amount of assembler needed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk