Является ли эта реализация С++ для безопасности Atomic?

Хорошо, крутой, я хочу Atomic float, а не для сверхбыстрого графического исполнения, но для регулярного использования в качестве членов данных классов. И я не хочу платить цену за использование замков в этих классах, потому что он не дает никаких дополнительных преимуществ для моих нужд.

Теперь с intel tbb и другими атомными библиотеками, которые я видел, поддерживаются целочисленные типы, но не плавающие точки. Поэтому я продолжал и реализовал один, и он работает... но я не уверен, работает ли он ДЕЙСТВИТЕЛЬНО, или мне очень повезло, что он работает.

Кто-нибудь знает, если это не какая-то форма резьбы ереси?

Изменить: изменил size_t на uint32_t, как предложил Грег Роджерс, таким образом его более портативный

Изменить: добавлено листинг для всего, с некоторыми исправлениями.

Дополнительные изменения: Производительность с использованием заблокированного поплавка для 5.000.000 + = операций со 100 потоками на моей машине занимает 3,6 с, а мой атомный флот даже с его глупым занятием занимает 0,2 с выполнять ту же работу. Таким образом, повышение производительности > 30x означает его ценность (и это улов), если это правильно.

Еще больше изменений: Как сказал Awgn, мои части fetch_and_xxxx были неправильными. Исправлено это и удаленные части API, о которых я не уверен (шаблонные модели памяти). И реализованы другие операции с точки зрения оператора + =, чтобы избежать повторения кода

Добавлено: Добавлен оператор * = и operator/=, так как floats не будут плавать без них. Спасибо Peterchen за комментарий, что это было замечено

Изменить: Ниже приведена последняя версия кода (я оставлю старую версию для справки)

Ответы

Ответ 1

Я бы серьезно советовал против публичного наследования. Я не знаю, что такое реализация атома, но я предполагаю, что это перегруженные операторы, которые используют его как интегральный тип, а это означает, что эти рекламные акции будут использоваться вместо вашего поплавка во многих случаях (возможно, в большинстве?).

Я не вижу причин, почему это не сработает, но, как и вы, мне нужно доказать, что...

Одна нота: ваша подпрограмма operator float() не имеет семантики получения нагрузки, и не следует ли ее отмечать как const volatile (или определенно, по крайней мере, const)?

EDIT: если вы собираетесь предоставить оператор -(), вы должны предоставить как префиксные, так и постфиксные формы.

Ответ 2

Похоже, ваша реализация предполагает, что sizeof(size_t) == sizeof(float). Это всегда будет верно для ваших целевых платформ?

И я бы не стал называть ересь так же, как бросать ересь.:)

Ответ 3

Это состояние кода в том виде, в каком оно стоит сейчас, после переговоров на платах Intel, но до сих пор не было полностью проверено на правильность работы во всех сценариях.

  #include <tbb/atomic.h>
  typedef unsigned int      uint_32;
  typedef __TBB_LONG_LONG       uint_64;

  template<typename FLOATING_POINT,typename MEMORY_BLOCK>
  struct atomic_float_
  {
    /*  CRC Card -----------------------------------------------------
    |   Class:          atmomic float template class
    |
    |   Responsability: handle integral atomic memory as it were a float,
    |                   but partially bypassing FPU, SSE/MMX, so it is
    |                   slower than a true float, but faster and smaller
    |                   than a locked float.
    |                       *Warning* If your float usage is thwarted by
    |                   the A-B-A problem this class isn't for you
    |                       *Warning* Atomic specification says we return,
    |                   values not l-values. So  (i = j) = k doesn't work.
    |
    |   Collaborators:  intel tbb::atomic handles memory atomicity
    ----------------------------------------------------------------*/
    typedef typename atomic_float_<FLOATING_POINT,MEMORY_BLOCK> self_t;

    tbb::atomic<MEMORY_BLOCK> atomic_value_;

    template<memory_semantics M>
    FLOATING_POINT fetch_and_store( FLOATING_POINT value ) 
    {
        const MEMORY_BLOCK value_ = 
            atomic_value_.tbb::atomic<MEMORY_BLOCK>::fetch_and_store<M>((MEMORY_BLOCK&)value);
        //atomic specification requires returning old value, not new one
        return reinterpret_cast<const FLOATING_POINT&>(value_);
    }

    FLOATING_POINT fetch_and_store( FLOATING_POINT value ) 
    {
        const MEMORY_BLOCK value_ = 
            atomic_value_.tbb::atomic<MEMORY_BLOCK>::fetch_and_store((MEMORY_BLOCK&)value);
        //atomic specification requires returning old value, not new one
        return reinterpret_cast<const FLOATING_POINT&>(value_);
    }

    template<memory_semantics M>
    FLOATING_POINT compare_and_swap( FLOATING_POINT value, FLOATING_POINT comparand ) 
    {
        const MEMORY_BLOCK value_ = 
            atomic_value_.tbb::atomic<MEMORY_BLOCK>::compare_and_swap<M>((MEMORY_BLOCK&)value,(MEMORY_BLOCK&)compare);
        //atomic specification requires returning old value, not new one
        return reinterpret_cast<const FLOATING_POINT&>(value_);
    }

    FLOATING_POINT compare_and_swap(FLOATING_POINT value, FLOATING_POINT compare)
    {
        const MEMORY_BLOCK value_ = 
            atomic_value_.tbb::atomic<MEMORY_BLOCK>::compare_and_swap((MEMORY_BLOCK&)value,(MEMORY_BLOCK&)compare);
        //atomic specification requires returning old value, not new one
        return reinterpret_cast<const FLOATING_POINT&>(value_);
    }

    operator FLOATING_POINT() const volatile // volatile qualifier here for backwards compatibility 
    {
        const MEMORY_BLOCK value_ = atomic_value_;
        return reinterpret_cast<const FLOATING_POINT&>(value_);
    }

    //Note: atomic specification says we return the a copy of the base value not an l-value
    FLOATING_POINT operator=(FLOATING_POINT rhs) 
    {
        const MEMORY_BLOCK value_ = atomic_value_.tbb::atomic<MEMORY_BLOCK>::operator =((MEMORY_BLOCK&)rhs);
        return reinterpret_cast<const FLOATING_POINT&>(value_);
    }

    //Note: atomic specification says we return an l-value when operating among atomics
    self_t& operator=(self_t& rhs) 
    {
        const MEMORY_BLOCK value_ = atomic_value_.tbb::atomic<MEMORY_BLOCK>::operator =((MEMORY_BLOCK&)rhs);
        return *this;
    }

    FLOATING_POINT& _internal_reference() const
    {
        return reinterpret_cast<FLOATING_POINT&>(atomic_value_.tbb::atomic<MEMORY_BLOCK>::_internal_reference());
    }

    FLOATING_POINT operator+=(FLOATING_POINT value)
    {
        FLOATING_POINT old_value_, new_value_;
        do
        {
            old_value_ = reinterpret_cast<FLOATING_POINT&>(atomic_value_);
            new_value_ = old_value_ + value;
        //floating point binary representation is not an issue because
        //we are using our self compare and swap, thus comparing floats and floats
        } while(self_t::compare_and_swap(new_value_,old_value_) != old_value_);
        return (new_value_); //return resulting value
    }

    FLOATING_POINT operator*=(FLOATING_POINT value)
    {
        FLOATING_POINT old_value_, new_value_;
        do
        {
            old_value_ = reinterpret_cast<FLOATING_POINT&>(atomic_value_);
            new_value_ = old_value_ * value;
        //floating point binary representation is not an issue becaus
        //we are using our self compare and swap, thus comparing floats and floats
        } while(self_t::compare_and_swap(new_value_,old_value_) != old_value_);
        return (new_value_); //return resulting value
    }

    FLOATING_POINT operator/=(FLOATING_POINT value)
    {
        FLOATING_POINT old_value_, new_value_;
        do
        {
            old_value_ = reinterpret_cast<FLOATING_POINT&>(atomic_value_);
            new_value_ = old_value_ / value;
        //floating point binary representation is not an issue because
        //we are using our self compare and swap, thus comparing floats and floats
        } while(self_t::compare_and_swap(new_value_,old_value_) != old_value_);
        return (new_value_); //return resulting value
    }

    FLOATING_POINT operator-=(FLOATING_POINT value)
    {
        return this->operator+=(-value); //return resulting value
    }

    //Prefix operator
    FLOATING_POINT operator++()
    {
        return this->operator+=(1); //return resulting value
    }

    //Prefix operator
    FLOATING_POINT operator--() 
    {
        return this->operator+=(-1); //return resulting value
    }

    //Postfix operator
    FLOATING_POINT operator++(int)
    {
        const FLOATING_POINT temp = this;
        this->operator+=(1);
        return temp//return resulting value
    }

    //Postfix operator
    FLOATING_POINT operator--(int) 
    {
        const FLOATING_POINT temp = this;
        this->operator+=(1);
        return temp//return resulting value
    }

    FLOATING_POINT fetch_and_add( FLOATING_POINT addend ) 
    {
        const FLOATING_POINT old_value_ = atomic_value_;
        this->operator+=(addend);
        //atomic specification requires returning old value, not new one as in operator x=
        return old_value_; 
    }

    FLOATING_POINT fetch_and_increment() 
    {
        const FLOATING_POINT old_value_ = atomic_value_;
        this->operator+=(+1);
        //atomic specification requires returning old value, not new one as in operator x=
        return old_value_; 
    }

    FLOATING_POINT fetch_and_decrement() 
    {
        const FLOATING_POINT old_value_ = atomic_value_;
        this->operator+=(-1);
        //atomic specification requires returning old value, not new one as in operator x=
        return old_value_; 
    }
  };

  typedef atomic_float_<float,uint_32> AtomicFloat;
  typedef atomic_float_<double,uint_64> AtomicDouble;

Ответ 4

Хотя размер uint32_t может быть эквивалентен размеру float в данной дуге, путем переинтерпретации приведения из одного в другое, вы подразумеваете, что атомарные приращения, декременты и все остальные операции над битами семантически эквивалентны на обоих типах, которых нет в действительности. Я сомневаюсь, что он работает так, как ожидалось.

Ответ 5

Я сильно сомневаюсь, что вы получите правильные значения в fetch_and_add и т.д., так как добавление с плавающей точкой отличается от добавления int.

Вот что я получаю от этой арифметики:

1   + 1    =  1.70141e+038  
100 + 1    = -1.46937e-037  
100 + 0.01 =  1.56743e+038  
23  + 42   = -1.31655e-036

Итак, да, поточно, но не то, что вы ожидаете.

алгоритмы блокировки (оператор + и т.д.) должны работать над атомарностью (не проверял сам алгоритм..)

Другое решение: Поскольку это все дополнения и вычитания, вы можете дать каждому потоку свой собственный экземпляр, а затем добавить результаты из нескольких потоков.

Ответ 6

Просто примечание об этом (я хотел сделать комментарий, но, видимо, новым пользователям не разрешалось комментировать): Использование reinterpret_cast по ссылкам приводит к неправильному коду с gcc 4.1 -O3. Это, кажется, исправлено в 4.4, потому что там оно работает. Изменение reinterpret_casts на указатели, хотя и немного уродливое, работает в обоих случаях.

Ответ 7

Из моего чтения этого кода я был бы действительно сумасшедшим в таком компиляторе, чтобы выпустить сборку для этого, которая не была атомарной.

Ответ 8

Попросите компилятор сгенерировать код сборки и взгляните на него. Если операция больше, чем одна инструкция на языке сборки, то это не атомная операция и требует, чтобы блокировки работали правильно в многопроцессорных системах.

К сожалению, я не уверен, что верно и обратное: операции с одной инструкцией гарантированно являются атомарными. Я не знаю подробностей многопроцессорного программирования вплоть до этого уровня. Я мог бы сделать дело для любого результата. (Если кто-то еще имеет определенную информацию об этом, не стесняйтесь звонить.)