Re: [boost] Notice: Boost.Atomic (atomic operations library)

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:
>
> http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/architecture_support.html

Thanks, just what I need.

> (the tarball also contains the generated docs, still busy reworking to use 
> boostdoc)
>
>> 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... 

Hmmm....

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.

Cheers,  Phil.