Question

我希望确认我的方法非常快速，并且适用于使用C ++的大多数读者，单一编写器方法的共享资源的跨平台保护。它有利于编写者，当他们输入所有当前线程时，允许完成，但任何类型的所有新线程都必须等待。这两个功能的反面应该是显而易见的。

我所做的阅读表明，boost shared_mutex 和其他类型的rwlock没有很好地实现，应该避免。事实上，shared_mutex不会进入 C ++ 0x 我接受它。见Anthony Williams的this response。

似乎甚至可以写入整数，如果正确对齐则不需要锁定任何类型。那里有很多文章，关于这个主题的任何好的阅读，所以我不需要从谷壳中分拣小麦？

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的决定与任何质量问题无关。该决定是2007年秋季“Kona妥协”的一部分。此妥协旨在减少C ++ 0x的功能集，以便在2009年之前发布标准。它没有用，但尽管如此，是理由。

在委员会完成C ++ 0x之后，将讨论包含在技术报告（即tr2）中的shared_mutex。图书馆工作组的主席已就此问题与我联系。这并不是说shared_mutex将在tr2中。只是它将被讨论。

你对AquireReadLock和AquireWriteLock的实现有一个缺点，就是它们在争用时以每秒一次的速度吃堆栈帧。当争用结束时，他们会在做出反应之前延迟一秒钟。这使得他们既挨饿又表现不佳（对不起）。

如果您有兴趣，请在此处详细描述和实施shared_mutex：

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

代码不是boost的一部分，但确实带有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 / C读/写互斥实现。如果你有关于如何改进它的想法，我会欢迎他们。

Answer 2

我想确认我的方法非常快适合跨平台保护共享资源主要是多个读者，单个作家使用C ++的方法。

比什么更快？您的问题似乎是微观优化，任何解决方案都需要进行分析才能得出充分的结论。

我所做的阅读表明了这一点启动shared_mutex和其他类型 rwlocks实现得不是很好应该避免。

您对此声明的来源是什么？

共享资源最快的多读/单写保护 - C ++

2 个答案: