Re: [Threads-devel] Extend shared_mutex with support for priority policies?

Subject: Re: [Threads-devel] Extend shared_mutex with support for priority policies?
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-05-11 14:34:08

On 15/12/2012 19.16, Fredrik Orderud wrote:
> The current "fair" shared_mutex implementation is great in the sense
> that it neither favors readers nor writers. This is probably a good
> property in most situations.
>
> However, there are situations where either reader or writer
> prioritization can be beneficial. In particular, I'm working on a
> project where the locking could be significantly stricter without
> risking introducing deadlocks if read-locks could be guaranteed to have
> priority over write-locks. I fully understand that a read- or
> write-priority implementation might have a bigger overhead compared to
> the existing "fair" shared_mutex implementation, but that is unlikely to
> be a problem for me.
>
> Is anyone in the boost community experiencing similar problems and/or is
> there any interest in extending shared_mutex with support for different
> priority policies?

Why do you say fair? Current mutexes (shared or not) implementation in 
boost is all but fair, that's why (at my understanding) at least on
Linux they are based on pthread mutexes (they are not fair / fifo).

Personaly speaking in boost in my daily job I'm missing

1) Deadlock detection
2) Fair mutexes to avoid starvation or lock convoy.

One of those "do not procrastinate day" I have to implement my own fair
mutexes based on boost ones, I have in mind two ways to do it:

a) Using a list of conditions, one per each thread waiting (locked)
b) Using a single condition but with a "tickets" incremented with
    atomic way, the lock would be something like:

      lock () {
         const this_thread_ticket = fetch_and_add(ticket)
         mutex.lock();
         while (current_ticket != this_thread_ticket) {
           cond.wait(mutex);
         }
      }

      unlock() {
        atomic_add(current_ticket);
        cond.notify_all();
        mutex.unlock();
      }

Regards