[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-users
Subject:    [Boost-users] =?utf-8?q?=5Bthread=5DIs_shared=5Fmutex_recursive_w?=
From:       Ken Savela <ksavela () msn ! com>
Date:       2008-12-29 15:25:40
Message-ID: loom.20081229T150554-820 () post ! gmane ! org
[Download RAW message or body]

In other words, should the following code result in a deadlock?



#include <iostream>

#include <boost/thread.hpp>

int main(int argc, char* argv[])
{
   boost::shared_mutex smx;

   boost::upgrade_lock<boost::shared_mutex> lock_one(smx);
   std::cout << "Locked once." << std::endl;
   std::cout.flush();
   boost::upgrade_lock<boost::shared_mutex> lock_two(smx);
   std::cout << "Locked again." << std::endl;
   std::cout.flush();
   boost::upgrade_to_unique_lock<boost::shared_mutex> lock_three(lock_two);
   std::cout << "Write lock." << std::endl;

   return 0;
}



This example illustrates the problem I'm having in my app -- I have a 
situation where a single thread may end up performing more than a single 
shared lock.  When it does so, it hangs on the nested upgrade_lock.  Is this 
the expected behavior?



_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
[prev in list] [next in list] [prev in thread] [next in thread]