Re: [Threads-devel] shared_mutex strategy

Subject: Re: [Threads-devel] shared_mutex strategy
From: Jérémy Coulon (jeremy.coulon_at_[hidden])
Date: 2010-05-24 07:10:00

Hi,

Please consider the following piece of code :

#include <boost/thread/thread.hpp>

#include <boost/thread/mutex.hpp>

#include <iostream>

boost::shared_mutex mux;

boost::mutex io_mux;

void msg(const char *str)

{

boost::mutex::scoped_lock l(io_mux);

std::cout << str << std::endl;

}//msg

void share()

{

mux.lock_shared();

msg("shared - lock_shared acquired");

boost::this_thread::sleep(boost::posix_time::seconds(5));

msg("shared - unlocking shared");

mux.unlock_shared();

}//share

void unique()

{

msg("unique - try_lock");

while (!mux.try_lock())

{

boost::this_thread::sleep(boost::posix_time::seconds(1));

msg("unique - try_lock");

}//while

msg("unique - acquired, unlocking");

mux.unlock();

}//unique

int main()

{

boost::thread_group tg;

tg.create_thread(share);

boost::this_thread::sleep(boost::posix_time::seconds(2));

tg.create_thread(unique);

boost::this_thread::sleep(boost::posix_time::seconds(2));

tg.create_thread(share);

tg.join_all();

return 0;

}//main

The result is :
shared - lock_shared acquired
unique - try_lock
unique - try_lock
shared - lock_shared acquired
unique - try_lock
shared - unlocking shared
unique - try_lock
unique - try_lock
unique - try_lock
unique - try_lock
shared - unlocking shared
unique - try_lock
unique - acquired, unlocking

So, in that situation, I think the writer is starving !
Do you agree ?

Jeremy

Le 20/05/2010 23:14, Damien R. a écrit :
> On 05/20/2010 06:18 PM, Chris M. Thomasson wrote:
>> "Chris M. Thomasson" <cristom_at_[hidden]> wrote in message
>> news:ht1k6u$rde$1_at_dough.gmane.org...
>>> "Damien R" <damienrg+list_at_[hidden]> wrote in message
>>> news:4BF3A2C0.6010606_at_gmail.com...
>>>> Anthony Williams wrote:
>>>>> If a reader gets the lock first, then more readers will be allowed
>>>>> to get the lock until a waiting writer wakes and registers its 
>>>>> intent.
>>>>
>>>> Yes, so in the worst case, only one reader will be able to read 
>>>> because
>>>> when the last reader unlocks the mutex, it notifies all waiters. 
>>>> For eg:
>>>> ----
>> [...]
>>>> ----
>>>>
>>>> Do you agree ?
>>>
>>> I have no time to make a proper response; sorry! Anyway...
>>>
>>>
>>> FWIW, I have created another "contention strategy" for an older
>>> read/write mutex algorithm of mine that totally eliminates any
>>> possible chance of starvation and is 100% fair.
>> [...]
>>> Here is some further context:
>>>
>>>
>>> http://relacy.pastebin.com/f3cab2025
>>> (the algorithm implemented in Relacy Race Detector)
>> [...]
>>
>> Read all:
>>
>> http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/65822 
>>
>>
>
> Thanks for all these links and for introducing me to Relacy Race 
> Detector. I will look closer at your code when I will be more familiar 
> with Relacy Race Detector.
>
>> One more thing Damien... You mentioned that you only have a single
>> writer that seldom requests exclusive access. IMHO, you should try
>> experimenting with a simple distributed rw-mutex design. Here is some
>> pseudo-code:
>> _____________________________________________________________
>> struct thread
>> {
>> mutex m_mutex;
>>
>> void read_lock()
>> {
>> m_mutex.lock();
>> }
>>
>> void read_unlock()
>> {
>> m_mutex.unlock();
>> }
>>
>> };
>>
>>
>> struct rwmutex
>> {
>> collection<thread*> m_threads;
>> mutex m_mutex;
>>
>> void register(thread* t)
>> {
>> mutex::scoped_lock lock(m_mutex);
>> m_threads.push(t);
>> }
>>
>> void unregister(thread* t)
>> {
>> mutex::scoped_lock lock(m_mutex);
>> m_threads.pop(t);
>> }
>>
>> void write_lock()
>> {
>> m_mutex.lock();
>>
>> for each thread in `m_threads' as i
>> {
>> i->read_lock();
>> }
>> }
>>
>> void write_unlock()
>> {
>> for each thread in `m_threads' as i
>> {
>> i->read_unlock();
>> }
>>
>> m_mutex.unlock();
>> }
>>
>> };
>>
>>
>> _____________________________________________________________
>>
>>
>> This has some fairly decent scalability characteristics and,
>> registration aside for a moment, moves the heavy lifting to writers
>> which should be few and far between. IIRC, this type of lock is called a
>> `brlock' in Linux. One other thing... This design is extremely portable!
>>
>> :^)
>>
>
> I did not know it, I will take a look.
>
> Thanks you very much for these advices.
> _______________________________________________
> threads-devel mailing list
> threads-devel_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/threads-devel
>