[cpp-threads] Re: Increment/decrement operators on atomics package

[Roger Orr]

cpp-threads-bounces at decadentplace.org.uk wrote:
>> -----Original Message-----
>> From:  Lawrence Crowl
>> Sent: Friday, April 20, 2007 5:45 AM
>> To: Raul Silvera
>> Cc: C++ threads standardisation
>> Subject: [cpp-threads] Re: Increment/decrement operators on atomics
>> package 
>> 
>> On 4/20/07, Raul Silvera <rauls at ca.ibm.com> wrote:
>>> 
>>> Lawrence, something that we briefly touched on in Oxford was the
>>> question of increment operators in the atomics package doing a RMW
>>> operation. 
>>> 
>>> I think that it is in generally confusing for t+=1 and t=t+1 to have
>>> different semantics for an Atomic t.

[snip]

>>> My proposal for this issue is to make t+=1 have the same semantics
>>> as t=t+1 (no RMW). Instead, a separate member functions would be
>>> provided to do RMW operations (e.g t.atomic_inc(1)).
>>> An alternative proposal would be not to define increment operators
>>> for the atomic class. 
>>> 
>>> Do you consider this a valid concern? Thanks...
>> 
>> I consider it a valid concern

Likewise.

Perhaps we should try to forbid t = t + 1 ?
Do we necessarily need/want to provide an implicit conversion from 
atomic<int> to int?
My limited experience concurs with Hans' that users tend to assume 
all valid operations with atomics are 'magically' atomic.

On the other hand named functions are harder to use with algorithms
expressed as templates - but how much might this matter?

--

On another issue, I was wondering about a refactor of Lawrence's example:
http://wiki.dinkumware.com/twiki/pub/Wg21oxford/EvolutionWorkingGroup/new_at
omic_syntax.c

I'm thinking about our discussion at Oxford over making it easier for 
people to stick with ordered operations for atomic<T>, and to have a
less obvious way to do the relaxed operations.
We were discussing another class, derived from atomic<T>, tentatively
named weak_atomic<T>.
Two downsides I see with this approach are
- problems interoperating atomic<T> in C++ with between C code
- extra clases and member functions for some code that we anticipate
  will be mostly *only* be used by experts.

By analogy with std::string and c_str() returning a raw pointer, how 
about if atomic<int> *contains* an atomic_int and has a method to 
return a pointer to it?

Then atomic<T> could just contain member functions for the safer 
operations, but advanced users could explicitly drop into the 'raw'
C-style functions to
(a) use the full range of functions or
(b) to interoperate with C code.
The (named) conversion function can more easily be grepped to find
uses.

Roger.