Fastest Multi-Reader / Single Writer Protection for Shared Resources - C++

问题

I would like confirmation that my approach is extremely fast and appropriate for cross platform protection of a shared resource for a mostly multiple reader, single writer approach using C++. It favors writers such that when they enter all current threads are allowed to finish, but all new threads of any type must wait. The reverse of these two functions should be obvious.

The reading I've done suggest that boost shared_mutex and other type rwlocks are not implemented very well and should be avoided. In fact, shared_mutex will not make it into C++0x I take it. See this response by Anthony Williams.

It seems it might even be possible to write to an integer and not need locking of any kind if it is aligned correctly. There is so many articles out there, any good reading on this subject so I don't have to sort the wheat from the chaff?

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;
    }   
}

回答1:

The decision to leave shared_mutex was made independently of any quality issues. The decision was part of the "Kona compromise" made in the Fall of 2007. This compromise was aimed at reducing the feature set of C++0x so as to ship a standard by 2009. It didn't work, but nevertheless, that is the rationale.

shared_mutex's will be discussed for inclusion to a technical report (i.e. tr2) after the committee has completed C++0x. The chairman on the library working group has already contacted me on this very subject. That is not to say that shared_mutex will be in tr2. Just that it will be discussed.

Your implementation of AquireReadLock and AquireWriteLock have the disadvantage in that they eat a stack frame at the rate of once per second when under contention. And when contention is over, they delay up to a second before reacting. This makes them both stack hungry and poor performing (sorry).

If you are interested, there is a full description and implementation of shared_mutex here:

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

The code is not part of boost, but does carry the boost open source license. Feel free to use it, just keep the copyright with the source code. No other strings attached. Here is its analog to your 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;
}

And here is its analog to your 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);
}

I consider this a well-tested and high-performing, fair read/write mutex implementation for C++. If you have ideas on how to improve it, I would welcome them.

回答2:

I would like confirmation that my approach is extremely fast and appropriate for cross platform protection of a shared resource for a mostly multiple reader, single writer approach using C++.

Faster than what? Your question seems like a micro-optimization, any solution will require profiling to make an adequate conclusion.