July 2010 - Boost-users - lists.preview.boost.org

[smart_ptr] No locks in quick allocator for shared pointers
by Manish Vachharajani 21 Jul '10

21 Jul '10

I was wondering if there was a standard way to turn off locks in the quick allocator for smart_ptr without disabling threading for all of Boost? It appears that the scoped_locks in the quick allocator are controlled by BOOST_HAS_THREADS. In turn, BOOST_HAS_THREADS seems to be controllable via BOOST_DISABLE_THREADS. However, I do not want to use this option as I need to link multiple programs against the same boost non-header libraries. Some programs have threading others do not. I want to be able to selectively disable locking for the non-threaded programs. If there is not better way to do this, the patch below adds a BOOST_QA_DISABLE_THREADS that will eliminate the scoped locks. --- .../boost/smart_ptr/detail/quick_allocator.hpp | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/ext/boost_1_43_0/boost/smart_ptr/detail/quick_allocator.hpp b/ext/boost_1_43_0/boost/smart_ptr/detail/quick_allocator.hpp index 159bd5e..ed878cb 100644 --- a/ext/boost_1_43_0/boost/smart_ptr/detail/quick_allocator.hpp +++ b/ext/boost_1_43_0/boost/smart_ptr/detail/quick_allocator.hpp @@ -70,7 +70,7 @@ template<unsigned size, unsigned align_> struct allocator_impl #endif -#ifdef BOOST_HAS_THREADS +#if defined(BOOST_HAS_THREADS) && !defined(BOOST_QA_DISABLE_THREADS) static lightweight_mutex & mutex() { @@ -89,7 +89,7 @@ template<unsigned size, unsigned align_> struct allocator_impl static inline void * alloc() { -#ifdef BOOST_HAS_THREADS +#if defined(BOOST_HAS_THREADS) && !defined(BOOST_QA_DISABLE_THREADS) lightweight_mutex::scoped_lock lock( mutex() ); #endif if(block * x = free) @@ -119,7 +119,7 @@ template<unsigned size, unsigned align_> struct allocator_impl } else { -#ifdef BOOST_HAS_THREADS +#if defined(BOOST_HAS_THREADS) && !defined(BOOST_QA_DISABLE_THREADS) lightweight_mutex::scoped_lock lock( mutex() ); #endif if(block * x = free) @@ -144,7 +144,7 @@ template<unsigned size, unsigned align_> struct allocator_impl { if(pv != 0) // 18.4.1.1/13 { -#ifdef BOOST_HAS_THREADS +#if defined(BOOST_HAS_THREADS) && !defined(BOOST_QA_DISABLE_THREADS) lightweight_mutex::scoped_lock lock( mutex() ); #endif block * pb = static_cast<block *>(pv); @@ -161,7 +161,7 @@ template<unsigned size, unsigned align_> struct allocator_impl } else if(pv != 0) // 18.4.1.1/13 { -#ifdef BOOST_HAS_THREADS +#if defined(BOOST_HAS_THREADS) && !defined(BOOST_QA_DISABLE_THREADS) lightweight_mutex::scoped_lock lock( mutex() ); #endif block * pb = static_cast<block *>(pv); @@ -171,7 +171,7 @@ template<unsigned size, unsigned align_> struct allocator_impl } }; -#ifdef BOOST_HAS_THREADS +#if defined(BOOST_HAS_THREADS) && !defined(BOOST_QA_DISABLE_THREADS) template<unsigned size, unsigned align_> lightweight_mutex * allocator_impl<size, align_>::mutex_init = &allocator_impl<size, align_>::mutex(); -- 1.7.0.1 Manish

1 0

PBGL Compile error on windows.
by Khaldoun "Hal" Alaqqad 21 Jul '10

21 Jul '10

I am trying to build the PBGL's boost_graph_mpi on windows 7 64bit. I generated the project files for VS 8/9/10, however the build has consistently shown compile errors: distributed_property_map.hpp(240): error C3855: 'boost::parallel::detail::associative_cache_ghost_cell_storage': template parameter 'Associativity' is incompatible with the declaration I tried to look for hints anywhere on the web, but did not find anything. Can anybody advise. Thanks.

1 0

Multi_index composite_key~~
by isjk 21 Jul '10

21 Jul '10

hi all, now,I have a composite_key like this, struct leader_key : boost::multi_index::composite_key< channel_info, BOOST_MULTI_INDEX_MEMBER(channel_info, boost::uint64_t, st_md5_), BOOST_MULTI_INDEX_MEMBER(channel_info, boost::uint32_t, st_rank_), BOOST_MULTI_INDEX_MEMBER(channel_info, boost::uint8_t, st_degrees_), BOOST_MULTI_INDEX_MEMBER(channel_info, boost::uint8_t, st_lan_type_) > { }; I used "md5, rank, degrees, lan_type" to query. I want to the result like this, equal to md5, less than rank degrees from small to large equal to lan_type How should I do?

2 1

[BGL] request to be added to list of BGL users
by Nil Geisweiller 21 Jul '10

21 Jul '10

Hi, OpenCog, an open source Artificial General Intelligence framework project http://www.opencog.org/wiki/The_Open_Cognition_Project uses BGL and we'll be pleased to be added to the list of BGL Users. Should you need any more info let me know. Regards, Nil

2 4

Odd boost::filesystem path behaviour?
by Tim Rawlinson 21 Jul '10

21 Jul '10

Hi, The following seems wrong to me, specifically the behaviour on Windows: path("/c:/file") Linux Windows by iteration "/", "c:", "file" "/", "c:", "/", "file" root_path "/" "/" relative_path "c:/file" "file" Is this behaviour correct? For reference, the boost::filesystem documents says: "All basic_path string or sequence arguments that describe a path shall accept the portable pathname format, ...", which the above path seems to be but it is interpreting it in a platform specific and, to my eyes, incorrect way. - Tim

1 0

[thread/condition_variable] crashes in condition variable
by Dietmar Hummel 21 Jul '10

21 Jul '10

Hi all! I have a problem with the condition variable class. I wrote a sync object class (something which two threads have a reference to, the one is waiting on in in wait() the other will signal it with signal(). This is some pseudo code which illustrates my problem: function doSomething() { // the sync object is to keep this thread // waiting until the other one is done CPGSUSyncObject cSyncObject; // give a pointer of the sync object to another thread ... // at one time in the future the other thread will call // its signal routine which calls condition_variable::notify_all // wait until the other one has done its tasks cSyncObject.wait(); } My problem (as far as I can see it) is the following: condition_variable::notify_all() calls wake_waiters() but does further tasks after this call (I assume that wake_waiters() is doing the real signalling by the os?). But if I have the task switch fast enough, it may happen that my doSomething() method runs out of scope deleting cSyncObject which is itself deleting the condition_variable. So the vector iteration code in condition_variable::notify_all() crashes because the object is already destroyed... Any help or good hints are appreciated... Regards Dietmar

2 2

Segmentation fault in lagged fibonacci random number generator
by Moritz Beber 21 Jul '10

21 Jul '10

Dear boost users, I have a very strange segmentation fault in lagged fibonacci and unfortunately, I was not able to reduce the problem to a simple example yet. I know that stinks of the problem coming from my code but please bear with me for a moment. I have two classes that both use the same other class for some random number generation. The two classes differ only in one unrelated function. If I run my program with one class everything works just fine, if I run it with the other after a few iterations the error occurs. I have no idea why, since they both use the exact same class from which the error occurs. I use the following code to get my generators: typedef boost::uniform_smallint<short unsigned> Small; typedef boost::variate_generator<rfn::RandGen&, Small> Small_Number; Small* _us_dist = new Small(1, 20); Small_Number* _len_gen = new Small_Number(rfn::Mutation::_parameters->rng(), *_us_dist); Where rfn::Mutation::_parameters->rng() gives me a reference from a lagged_fibonacci object held in that class. I then try to get a number in the following way: short unsigned length = (*_len_gen)(); I have attached a gdb run of the program crashing. If you have any ideas where I can look for this error please tell me. It's also no problem for me to send you the complete sources but it's a rather big project. Thank you for your help, Moritz

3 3

true typedef (true_typedef) implemented in boost?
by alfC 20 Jul '10

20 Jul '10

Hi, I stumbled upon the concept of true typedef, or strong typedef in opposition to usual typedef which are weak. http://www.drdobbs.com/184401633, there is a true_typedef implemented in stlsoft http://www.stlsoft.org/doc-1.9/classstlsoft_1_1true__typedef.html I was wondering if this is already implemented in some corner of Boost, or as a detail implementation. If it is really a useful concept (I don't know) then, I though, Boost should have it somewhere. And if it doesn't have it then it must mean that Boosters come out with something even better. Did they? Thank you, Alfredo

6 10

[pool] Threadsafety
by Ruediger Berlich 20 Jul '10

20 Jul '10

Hi there, just to clarify: The pool documentation says in the "Object Usage vs. Singleton Usage" section (see here: http://www.boost.org/doc/libs/1_43_0/libs/pool/doc/interfaces.html): "Pool objects with Singleton Usage may be shared; thus, Singleton Usage implies thread-safety as well." So, with the singleton pool interface I can safely do concurrent mallocs and frees on all supported OSs (using Boost.Thread for the concurrency part), albeit at the expense of having a YASWIOI (yet another singleton with its own interface) in my programs, with all pros and cons that singletons have ? Thanks and Kind Regards, Ruediger Berlich

1 0

First set of Boostcon 2010 videos are available
by Marshall Clow 20 Jul '10

20 Jul '10

Almost all of the Transactional Memory sessions from Boostcon are now available, with the exception of Tatiana Shpeisman's presentation on the "Draft Specification of Transactional Language Constructs for C++". That talk should (hopefully) be available tomorrow. Here are the links Maurice Herlihy : Transactional Memory Today - Keynote: http://blip.tv/file/3900047/ Justin Gottschlich:TBoost.STM Engine: http://blip.tv/file/3900167/ Tatiana Shpeisman: Draft Specification of Transactional Language Constructs for C++: <coming soon> Michael Wong: IBM's TM Research: http://blip.tv/file/3900242/ Mark Moir: Sun's / Oracle's TM Research: http://blip.tv/file/3905166/ Tatiana Shpeisman: Intel's TM Research: http://blip.tv/file/3905189/ Hartmut - I apologize for removing your (very nice) introduction for Maurice from the video. Unfortunately, Maurice was wearing the microphone, and none of what you said could be heard. -- Marshall

2 1