- Boost-users - lists.boost.org

Troubleshooing deadlock with upgrade_lock<shared_mutex>
by Ken Smith 23 Apr '10

23 Apr '10

I'm a C++/boost newbie, so my apologies if this is a basic question. I've got a multithreaded app that appears to be deadlocking when two threads are trying to acquire an upgrade_lock<shared_mutex> at the same time. Specifically, I've got a class that looks something like this: #include <boost/thread.hpp> using namespace boost; class Manager { public: Manager(); ~Manager(); void createRoom(); void deleteRoom(); void transmit(); private: shared_mutex roomManagersMutex; }; void Manager::createRoom() { upgrade_lock<shared_mutex> upgradeLock(roomManagersMutex); // Read stuff if(roomShouldBeCreated) { upgrade_to_unique_lock<shared_mutex> uniqueLock(upgradeLock); // Create room } } void Manager::deleteRoom() { upgrade_lock<shared_mutex> upgradeLock(roomManagersMutex); // Read stuff if (roomShouldBeDeleted) { upgrade_to_unique_lock<shared_mutex> uniqueLock(upgradeLock); // Delete the room } } void Manager::transmit() { shared_lock<shared_mutex> lock(roomManagersMutex); // Read stuff about the room } The Manager::deleteRoom() and Manager::createRoom() methods are typically only called once every few seconds, but Manager::transmit() is called every 20 milliseconds or so, i.e., about 50 times / second. Periodically, the app stops responding. When it does, I can see that the transmit() method is working fine, but the createRoom() and deleteRoom() methods (on separate threads, obviously) appear to be deadlocked on the highlighted lines, waiting to acquire their upgrade_locks. Now that seems weird to me, because I thought the whole purpose of the upgrade locks was that they're supposed to be shared, right up until you request an upgrade to a unique lock. Obviously the code is more complex than what I've described, but it doesn't appear that there's a unique lock being held anywhere when the deadlock happens. Am I doing something wrong? Any suggestions on troubleshooting this? Ken Smith Cell: 425-443-2359 Email: smithkl42(a)gmail.com Blog: http://blog.wouldbetheologian.com/

2 3

tuple
by luca formaggia 23 Apr '10

23 Apr '10

Hello, someone could tell me what is wrong in this piece of code #include "boost/tuple/tuple.hpp" using namespace boost::tuples; int main(){ tuple<int, double> t2(); get<0>(t2)=int(10); } I get the following error message: g++ try.cpp try.cpp: In function ‘int main()’: try.cpp:5: error: no matching function for call to ‘get(boost::tuples::tuple<int, double, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> (&)()) In the tutorial it is written that tuple<int, double> t2() should construct the object via the default constructor. Why I cannot access the first element (it works if I give an initial value, for instance using tuple<int, double> t2(1); I get a similar error if I use the method get<N>() instead of the function. I am using gnu compiler gcc version 4.4.1 (GCC) in a i386 linux machine. Thank you, Luca -- Luca Formaggia

3 2

Boost graph write_graphml
by Theodore McCormack 23 Apr '10

23 Apr '10

I am having troubles figuring out how to use write_graphml from the documentation. My problem is in creating the dynamic_property. To access my vertex properties i use this: VERTEXPROPERTIES& properties(const Vertex& v) { typename property_map<GraphContainer, vertex_properties_t>::type param = get(vertex_properties, graph); return param[v]; } where VERTEXPROPERTIES is a type of a structure that i use for vertex properties. how would i go about creating a dynamic_property from that property map? Regards! Ted

2 1

Writing a function to use a generic random number generator
by Joseph Wakeling 23 Apr '10

23 Apr '10

Hello all, A question regarding Boost's random number generators. Here's a simple example use-case: ///////////////////////////////////////////////////////// #include <iostream> #include <vector> #include <boost/foreach.hpp> #include <boost/random.hpp> using namespace std; using namespace boost; void generate_random_numbers(vector<double> &x, mt19937 &rng) { BOOST_FOREACH(double &z, x) z = uniform_real<double> (0.0, 5.0) (rng); } int main() { mt19937 rng; vector<double> x; x.resize(1000); generate_random_numbers(x,rng); for(size_t i=0;i!=10;++i) cout << x.at(i) << endl; // and now do something fun with x ... :-) return 0; } ///////////////////////////////////////////////////////// The question is, how do I go about getting generate_random_numbers() to use an _arbitrary_ random number generator instead of having to be mt19937? In particular, is there a way to do this without needing to have a template function? Thanks & best wishes, -- Joe

1 0

Matrix Deallocation
by Marco Arena 23 Apr '10

23 Apr '10

Hi, I'm new of Boost! I'd like to deallocate a ublas::compressed_matrix. For example: typedef boost::numeric::ublas::compressed_matrix<double> Matrix; Matrix m = Matrix(10,10,5); // operations... // Deallocation Thanks and sorry if the question is too trivial. Best regards, Marco

1 0

Returning by value, was: [Range] non-const range reference
by Robert Jones 23 Apr '10

23 Apr '10

On Fri, Apr 23, 2010 at 9:51 AM, Neil Groves <neil(a)grovescomputing.com>wrote: > > On Thu, Apr 22, 2010 at 11:43 AM, Robert Jones <robertgbjones(a)gmail.com>wrote: > > >> Returning containers by value seems to be the 'right way' now, as RVO >> should >> sort out the copy elision. >> >> > I'm not convinced that this is the 'right way'. I find that for trivial > examples the copy is optimized away, but that on many compilers at various > levels of call depth the copy construction occurs causing a huge performance > degradation. I suspect that the 'right way' is still by using references in > C++03 and by using move constructors in C++0x. > > > This is concerning - anybody else have any experience to support this? My original remark was prompted by http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ penned by Dave A. If compilers don't really do this consistently I need to write my code rather differently by default! - Rob.

1 0

[Range] non-const range reference
by Robert Jones 23 Apr '10

23 Apr '10

I'm not able to use the latest Boost release, so I've plagarised some little bits that are useful, and in the process might have missed something, so bear with me. I have this bit of code... #include <algorithm> #include <boost/range.hpp> template < class SinglePassRange, class UnaryFunction > UnaryFunction for_each( SinglePassRange & rng, UnaryFunction fun ) { return std::for_each( boost::begin( rng ), boost::end( rng ), fun ); } struct A { }; void f( const A & ); std::vector< A > generateVec( ); int main( ) { for_each( generateVec( ), f ); } which understandably fails to compile as I'm passing an lvalue as non-const reference. I can fix this by adding a const ref overload of for_each, but no such overload exists in the real boost range header (AFAIK). Returning containers by value seems to be the 'right way' now, as RVO should sort out the copy elision. What I'm doing in this code seems reasonable - should it be supported by const ref overloads, or have I missed some 'gotcha' somewhere? Thanks, - Rob.

2 2

[program options] option_description name as string
by Anthony Foglia 22 Apr '10

22 Apr '10

We tend to store the names of our options in strings (so we can reuse them later when getting the values out of the variable map). But option_descriptions can only be created from const char *, so we need to add a .c_str() when building the options_description. Is there any reason why options can't be constructed with a string? Otherwise I'll open a feature request bug. -- Anthony Foglia Princeton Consultants (609) 987-8787 x233

2 2

time_t to ptime conversion problem
by Scott Vanderweyst 22 Apr '10

22 Apr '10

While doing some testing I've come across what I consider a bug in the boost::posix::from_time_t function. I'm running this on Visual studio 2005 due to needing to deal with some legacy code. I'm using boost v 1.39 - Issue is that if you create a time_t representing a date after Jan 18 2038 using standard functions, when the time_t is loaded into the ptime it's rolling back to 1901. In Visual studio 2005, time_t is 64 bit. Example code: #include <boost/date_time/posix_time/posix_time.hpp> #include <boost/date_time/posix_time/time_parsers.hpp> int main() { struct tm timeStruct; boost::posix_time::ptime boostTime; time_t timeVal; memset(&timeStruct, 0, sizeof(timeStruct)); timeStruct.tm_year = 138; timeStruct.tm_mon = 0; timeStruct.tm_mday = 18; timeVal = mktime(&timeStruct); std::cout << timeVal << std::endl; boostTime = boost::posix_time::from_time_t(timeVal); std::cout << boostTime << std::endl; memset(&timeStruct, 0, sizeof(timeStruct)); timeStruct.tm_year = 138; timeStruct.tm_mon = 0; timeStruct.tm_mday = 19; timeVal = mktime(&timeStruct); std::cout << timeVal << std::endl; boostTime = boost::posix_time::from_time_t(timeVal); std::cout << boostTime << std::endl; return 0; } which outputs: 2147403600 2038-Jan-18 05:00:00 2147490000 1901-Dec-13 22:31:44 which is not quite the result I was hoping for. Any suggestions other than not using time_t? ( It's been considered and rejected as a possibility for now) Thanks in advance Scott V

1 0

problem in porting my application to 1.42.0
by Mahmood Naderan 22 Apr '10

22 Apr '10

My project works fine with Boost 1.33.1 but when I want to make it with boost 1.42.0 I get several errors. In file included from /home/mahmood/boost_1_42_0/boost/multi_index_container_fwd.hpp:18, from /home/mahmood/boost_1_42_0/boost/multi_index_container.hpp:30, from BaseCacheControllerImpl.cpp:61: /home/mahmood/boost_1_42_0/boost/multi_index/indexed_by.hpp:61: error: wrong number of template arguments (50, should be 20) /home/mahmood/boost_1_42_0/boost/mpl/aux_/preprocessed/gcc/vector.hpp:22: error: provided for ‘template<class T0, class T1, class T2, class T3, class T4, class T5, class T6, class T7, class T8, class T9, class T10, class T11, class T12, class T13, class T14, class T15, class T16, class T17, class T18, class T19> struct boost::mpl::vector’ In file included from /home/mahmood/boost_1_42_0/boost/multi_index/detail/ord_index_args.hpp:21, from /home/mahmood/boost_1_42_0/boost/multi_index/ordered_index_fwd.hpp:16, from /home/mahmood/boost_1_42_0/boost/multi_index_container_fwd.hpp:19, from /home/mahmood/boost_1_42_0/boost/multi_index_container.hpp:30, from BaseCacheControllerImpl.cpp:61: /home/mahmood/boost_1_42_0/boost/multi_index/tag.hpp:79: error: wrong number of template arguments (50, should be 20) /home/mahmood/boost_1_42_0/boost/mpl/aux_/preprocessed/gcc/vector.hpp:22: error: provided for ‘template<class T0, class T1, class T2, class T3, class T4, class T5, class T6, class T7, class T8, class T9, class T10, class T11, class T12, class T13, class T14, class T15, class T16, class T17, class T18, class T19> struct boost::mpl::vector’ /home/mahmood/boost_1_42_0/boost/multi_index/tag.hpp:81: error: template argument 1 is invalid What happend to the indexed_by.hpp from 1.33.1 to 1.42.0. All ideas are welcomed. // Naderan *Mahmood;

2 1