Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-31 05:44:47

In message <00f601c012d2$8c07afc0$37781990_at_[hidden]>, Greg Colvin
<gcolvin_at_[hidden]> writes
>This one is necessary, but tough. On platforms which don't
>have the necessary instructions to do one of these operations
>atomically without a mutex they will be expensive, so I
>would lean more towards the minimal useful subset that is
>doable (often in only in assembly) on most machines without a

I would agree, which (looking at some of my code) means increment,
decrement and exchange. I think others should be considered later, but
documented as optional.

>For example, after an increment or decrement you may not have
>atomic access to the new value, but only to a condition code
>that tells you whether it is zero. So it might be better to
>return a bool from increment and decrement rather than force
>a slower implementation.

Yes, so they should definitely be modelled as "atomic counters" and not
as "atomic integers", which means no operator++ or operator-- to

As to whether these are operations on an opaque type or member
functions, I am not particularly concerned. However, if treated as a
class with member functions, it is easier to export a
counter::value_type for those cases it's needed (eg exchange), rather
than introduce YA traits class (the traits idiom is great, but too much
of a good thing...).

  Kevlin Henney phone: +44 117 942 2990
  Curbralan Ltd mobile: +44 7801 073 508
  kevlin_at_[hidden] fax: +44 870 052 2289

Boost list run by bdawes at, gregod at, cpdaniel at, john at