Re: RFC: Multithreading design constraints

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-06-05 10:43:14

--- In boost_at_[hidden], John Maddock <John_Maddock_at_c...> wrote:
> ATOMIC OPERATIONS
> ~~~~~~~~~~~~~~~~
> 
> Although not available on all platforms the performance gains 
available
> from native atomic operations can not be ignored, the question is 
which
> operations?  The following class may provide a starting point for an
> interface:
> 
> //
> // primary template, not thread safe:
> template <class T>
> struct atom_traits
> {
>         static const bool is_specialized = false;
>         // read:
>         static const bool has_read = false;
>         T read(volatile T* atom)
>         { return *atom; }
> 
>         // write:
>         static const bool has_write = false;
>         void write(volatile T* atom, const T& value)
>         { *atom = value; }
> 
>         // add:
>         static const bool has_add = false;
>         T add(volatile T* atom, const T& value)
>         { return *atom + value; }
> 
>         // test and set:
>         static const bool has_tas = false;
>         bool tas(volatile T* atom)
>         { bool result = (0 == *atom); *atom = 1; return result; }
> 
>         // test and reset:
>         static const bool has_tar = false;
>         bool tar(volatile T* atom)
>         { bool result = (0 != *atom); *atom = 0; return result; }
> 
>         // compare and exchange:
>         static const bool has_cxc = false;
>         bool cxc(volatile T* atom, T* with, const T& value)
>         { 
>                 if(value == *atom)
>                 { 
>                         std::swap(*atom, with) 
>                         return true;
>                 }
>                 return false;
>         }
> };

Good reasoning. However, in step with my previous comments, 
is_specialised and has_* should be removed. Even in absence of native 
atomic operations, all of these can be implemented in terms of mutex.

Cheers,

Miki.