#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

On 05/20/2010 06:18 PM, Chris M. Thomasson wrote:

"Chris M. Thomasson" <cristom@charter.net> wrote in message
news:ht1k6u$rde$1@dough.gmane.org...

"Damien R" <damienrg+list@gmail.com> wrote in message
news:4BF3A2C0.6010606@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@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/threads-devel