Самая быстрая защита нескольких читателей и одного записывающего устройства для общих ресурсов - C ++

Question

Я хотел бы получить подтверждение того, что мой подход чрезвычайно быстрый и подходит для межплатформенной защиты общего ресурса для подхода с несколькими читателями и одним писателем с использованием C ++. Авторы предпочитают, чтобы при их входе все текущие потоки могли завершаться, но все новые потоки любого типа должны ждать. Обратное из этих двух функций должно быть очевидным.

Чтение, которое я сделал, предполагает, что boost shared_mutex и другие типы блокировок не очень хорошо реализованы и их следует избегать. На самом деле, shared_mutex не превратится в C ++ 0x Я так понимаю. См. этот ответ Энтони Уильямса.

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

void AquireReadLock(void)
{
    mutex::enter();
    if(READ_STATE == true)
    {   
        iReaders++;
        mutex::leave();
        return;
    }
    else
    {
        mutex::leave();
        sleep(1);
        AquireReadLock();
        return;
    }   
}

void AquireWriteLock(void)
{
    mutex::enter();
    READ_STATE = false;
    if (iReaders != 0)
    {
        mutex::leave();
        sleep(1);
        AquireWriteLock();
        return;
    }
    else
    {
        mutex::leave();
        return;
    }   
}

Answer 1

Решение покинуть shared_mutex было принято независимо от каких-либо проблем с качеством.Это решение было частью «компромисса Kona», достигнутого осенью 2007 года. Этот компромисс был нацелен на сокращение набора функций C ++ 0x для обеспечения поставки стандарта к 2009 году. Это не сработало, но, тем не менее, этоявляется обоснованием.

shared_mutex будет обсуждаться для включения в технический отчет (т. е. tr2) после того, как комитет завершит C ++ 0x.Председатель рабочей группы библиотеки уже связался со мной по этому вопросу.Это не означает, что shared_mutex будет в tr2.Просто это будет обсуждаться.

Ваша реализация AquireReadLock и AquireWriteLock имеет недостаток в том, что они используют фрейм стека со скоростью один раз в секунду, когда находятся в состоянии конфликта.И когда спор закончен, они задерживаются до секунды, прежде чем реагируют.Это приводит к тому, что они и стекаются, и работают плохо (извините).

Если вам интересно, здесь есть полное описание и реализация shared_mutex:

http://home.roadrunner.com/~hinnant/mutexes/locking.html

Код не является частью Boost, но имеет расширенную лицензию с открытым исходным кодом.Не стесняйтесь использовать его, просто сохраните авторское право с исходным кодом.Других строк нет.Вот его аналог вашего AquireReadLock:

void
shared_mutex::lock_shared()
{
    std::unique_lock<mutex_t> lk(mut_);
    while ((state_ & write_entered_) || (state_ & n_readers_) == n_readers_)
        gate1_.wait(lk);
    count_t num_readers = (state_ & n_readers_) + 1;
    state_ &= ~n_readers_;
    state_ |= num_readers;
}

А вот его аналог вашему AquireWriteLock:

void
shared_mutex::lock()
{
    std::unique_lock<mutex_t> lk(mut_);
    while (state_ & write_entered_)
        gate1_.wait(lk);
    state_ |= write_entered_;
    while (state_ & n_readers_)
        gate2_.wait(lk);
}

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

Answer 2

Я хотел бы получить подтверждение того, что мой подход чрезвычайно быстр и подходит для кроссплатформенной защиты общего ресурса для подхода с несколькими читателями и одним писателем, использующего C ++.

Быстрее чем что?Ваш вопрос выглядит как микрооптимизация, любое решение требует профилирования, чтобы сделать адекватный вывод.

Чтение, которое я сделал, предполагает, что boot shared_mutex и rwlocks других типов не реализованы очень хорошо и должныследует избегать.

Каковы ваши источники этого утверждения?