Boost logo

Boost :

Subject: [boost] [thread] shared_spinlock_t idea or faster shared_lock
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-05-02 01:37:46


Hi,

This is just a refining of idea that was once implemented and worked well.
The idea was to make shared spin lock. Here is some pseudo-code:

class shared_spin_lock {
    atomic_max_uint_t state_;

lock_shared() {
    do { // CAS loop
        auto snapshot = state_.load();
        if (snapshot.has_writer_bit_set()) {
             reader_wait(); // waiting for writer to finish
             continue;
        }

        auto new_state = snapshot + 1;
     } while(!CAS(state, new_state));
}

unlock_shared() {
        --state;
}

lock() {
    do { // CAS loop
        auto snapshot = state_.load();
        if (snapshot.has_writer_bit_set()) {
             writer_wait(); // waiting for other writer to finish
             continue;
        }

        auto new_state = snapshot.set_writer_bit();
     } while(!CAS(state, new_state));

    // we have set the writer bit, now waiting for readers to finish
    while (state_.readers_count) ; // busy loop, can we do better?

     writer_started();
}

unlock() {
        auto snapshot = state_.reset_writer_bit();
        writer_finished();
        ASSERT (snapshot.has_writer_bit_set());
}

};

When all the *_wait() and writer_*() functions do nothing we get a shared
spinlock.

Now if we add helper mutex and make all the *_wait() functions to lock and
unlock mutex; writer_start() - lock the mutex; writer finished() - unlock
the mutex... we get a simplified shared_mutex that is faster (in theory)
than current implementation.

Is there an interest in such shared_spinlock_t? Any comments, suggestions?

-- 
Best regards,
Antony Polukhin

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk