$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [atomic] Support for specialized instructions
From: Tim Blechmann (tim_at_[hidden])
Date: 2013-11-21 04:04:41
hi andrey,
> I've been contemplating the idea of adding support for some
> specialized atomic instructions to Boost.Atomic. Since I'm only
> familiar with x86 architecture, my current candidates are:
>
> * Increment/decrement with a check for zero result (lock inc/dec). The
> decrement is the most essential of the two because it would be useful
> for reference counters of various kinds. The increment is mostly
> beneficial in terms of code size, and it probably doesn't need the
> check for zero in most cases.
>
> * In-place logical operations (lock and/or/xor). These are useful in
> cases when the code needs to operate on flags or bit sets but doesn't
> need the result of the operation. Optional variants can be provided
> with a test for zero result.
>
> * Bit set/reset operations (lock bts/btr). The use cases are similar
> to the logical operations but the advantage is that the previous value
> of the altered bit can be returned. BTW, these operations are needed
> in Boost.Sync to implement mutexes on Windows.
>
> All these operations can be implemented through the standard atomic<>
> interface, and that's what would be done on platforms without support
> for the specialized instructions.
>
> For now the idea is to add special member functions to atomic<>, when
> used with arithmetic types. I was thinking about providing free
> functions as well, although I think that the complete set of the
> standard atomic functions would be required for that.
>
> Comments? Opinions?
hmmm, i see your points ... however in a way, i'd prefer if this
functionality could be built upon boost.atomic, mainly to keep API
compatibility with std::atomics.
with compiler-support for c++11 atomics, the first two instructions
could probably be generated by a smart compiler ... bts/btr may be
useful, but i suppose they are rather specific to x86? i wonder, how
would they map to arm?
but, yes ... if you think it is reasonable to add them, please go ahead!
cheers,
tim