Блокированные операции с семантической сборкой и выпуском (мультиплатформенность) - PullRequest
3 голосов
/ 26 января 2011

РЕДАКТИРОВАТЬ: Хорошо, у меня есть конкретный вопрос.Я хочу реализовать функциональность 'exchange' с семантическим приобретением и выпуском (псевдокод):

interlocked_inc_32(target)
{
    mov  ecx, 1
    lea  eax, target
    lock xadd, [eax], ecx
}

interlocked_inc_32_acq(target)
{
    lfence
    mov  ecx, 1
    lea  eax, target
    lock xadd, [eax], ecx
}

interlocked_inc_32_rel(target)
{
    sfence
    mov  ecx, 1
    lea  eax, target
    lock xadd, [eax], ecx
}

Проблема в том, что я понятия не имею, как это реализовать.Я занимаюсь разработкой под Windows с помощью Microsoft Visual Studio 2010. Конечно, есть «intrin.h» и «Windows.h», которые предоставляют именно эти функции / встроенные функции.НО там InterlockedIncrementAcquire является просто определением для InterlockedIncrement и обеспечивает полный барьер памяти.Это не то, что я ищу.

/ **************************************** оригинальный пост: / ****************************************

Я хочу написать атомарный класс, такой как C ++ 0x std :: atomic.Я просто хочу быть уверен, что мои мысли об этом правильны.

Я хотел бы реализовать следующий код: РЕДАКТИРОВАТЬ (заменил плохую реализацию)

enum memory_order { memory_order_acquire, memory_order_release, memory_order_acq_rel };

template<class T> class atomic;
template<class atomic_type, std::size_t = sizeof(typename ExtractType<atomic_type>::type)> struct interlocked;

template<template<class> class atomic_type> struct interlocked<atomic_type, 1>
{
    typedef typename ExtractType<atomic_type>::type bit8_type;

    void store(bit8_type value, memory_order order = memory_order_acq_rel) volatile {
        interlocked_xchg_8<order>(&static_cast<atomic_type volatile*>(this)->m_value, value);  
    }

    bit8_type load(memory_order order = memory_order_acq_rel) const volatile
    { 
        interlocked_cmp_xchg_8<order>(
            const_cast<bit8_type volatile*>(&static_cast<volatile const atomic_type *const>(this)->m_value), 
            static_cast<atomic_type const volatile*>(this)->m_value, 
            static_cast<atomic_type const volatile*>(this)->m_value
        ); 
    }

    bit8_type exhange(bit8_type, memory_order order = memory_order_acq_rel) volatile {
        return interlocked_xchg_8<order>(&static_cast<atomic_type volatile*>(this)->m_value, value);
    }

    bool compare_exchange(bit8_type comperand, bit8_type new_value, memory_order order = memory_order_acq_rel) volatile 
    {
        return interlocked_cmp_xchg_8<order>(
            &static_cast<atomic_type volatile*>(this)->m_value,
            new_value,
            comperand
        ) == comperand;

    }
};

template<template<class> class atomic_type> struct interlocked<atomic_type, 2> { };
template<template<class> class atomic_type> struct interlocked<atomic_type, 4> { };
template<template<class> class atomic_type> struct interlocked<atomic_type, 8> { };


template<class T>
class atomic : public interlocked<atomic<T>> { T m_value; };

Есть ли что-то, что я 'm отсутствует или это «хорошая» и неплохая реализация.

Спасибо за любой комментарий.С наилучшими пожеланиями:

PS: я не хочу начинать новый вопрос для этого: в чем преимущество использования boost :: uint32_t (в boost \ cstdint.h) вместо uint32_t (в stdint.h)

Ответы [ 2 ]

3 голосов
/ 03 февраля 2011

Вы ориентируетесь на аппаратное обеспечение x86?Разве его схема синхронизации кеша не подразумевает, что вы получаете полный барьер памяти?Как вы пытаетесь улучшить это?

2 голосов
/ 18 апреля 2011

Проблема, с которой вы здесь сталкиваетесь, заключается в том, что префикс блокировки подразумевает полный барьер памяти (mfence).Это потому, что на предыдущих процессорах x86 не было разного рода барьеров памяти и отдельных инструкций sfence / lfence.

...