- Boost - lists.boost.org

Problems with conditions in boost::thread
by Andreas Pokorny 27 Jun '04

27 Jun '04

Hi, I just started to use boost::thread in a bigger application. Since the condition variables do not work as expected - e.g. the waiting thread never wakes up ( example can be found here: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp ) - I started writing a smaller test case to see if I use the library correctly. That little test application works fine if I run it in with the gnu debugger, and if I have debugging symbols in my glibc. In all other cases the process gets terminated before any debuging print outs show up or the debugger fails to run the application: #include <list> #include <iostream> #include <boost/bind.hpp> #include <boost/thread/xtime.hpp> #include <boost/thread/thread.hpp> using namespace boost; struct Mini { bool running; thread worker; mutex list_mutex; condition items_empty; std::list<std::string> items; typedef mutex::scoped_lock lock; Mini(); ~Mini(); void run(); void add( std::string const& item); }; Mini::Mini() : worker( bind( &Mini::run, this ) ) { } Mini::~Mini() { running = false; { lock the_list( list_mutex ); items_empty.notify_one(); } worker.join(); } void Mini::run() { running = true; while( running ) { lock the_list( list_mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; items_empty.wait( the_list ); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); } } void Mini::add( std::string const& item ) { lock list_access( list_mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; items_empty.notify_one(); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); xtime xt; xtime_get(&xt, TIME_UTC); xt.sec += 2; thread::sleep(xt); } After that I tried to do it without boost. This time everything works as expected, with and without debugger. #include <list> #include <unistd.h> #include <iostream> #include <pthread.h> struct Mini { bool running; pthread_t worker; pthread_mutex_t mutex; pthread_cond_t not_empty; std::list<std::string> items; Mini(); ~Mini(); static void * call_run( void *); void run(); void add( std::string const& item); }; void* Mini::call_run( void * ptr) { static_cast<Mini*>(ptr)->run(); return 0; } Mini::Mini() { pthread_mutex_t temp_mut = PTHREAD_MUTEX_INITIALIZER; mutex = temp_mut; pthread_cond_t temp_cond = PTHREAD_COND_INITIALIZER; not_empty = temp_cond; worker = pthread_create( &worker, 0, Mini::call_run, this ); } Mini::~Mini() { running = false; { pthread_mutex_lock( &mutex ); pthread_cond_broadcast( &not_empty ); pthread_mutex_unlock( &mutex ); } pthread_join( worker, 0 ); pthread_cond_destroy( &not_empty ); } void Mini::run() { running = true; while( running ) { pthread_mutex_lock( & mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; pthread_cond_wait(&not_empty, &mutex); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); pthread_mutex_unlock( &mutex ); } } void Mini::add( std::string const& item ) { pthread_mutex_lock( & mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; pthread_cond_broadcast(& not_empty); pthread_mutex_unlock( &mutex ); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); sleep(2 ); } Any ideas?

2 2

Autolinking problem on Intel (Win32) with STLport
by Doug Gregor 26 Jun '04

26 Jun '04

It looks like there is a problem with autolinking as mentioned in the subject. It looks like a library naming issue: http://tinyurl.com/2djmv Doug

2 2

How to use boost::thread::condition
by Andreas Pokorny 26 Jun '04

26 Jun '04

Hi, I have problems understanding how mutexes, scoped locks and conditions should work togehter. I took the condition.cpp example and with the buffered shared by two threads as a basis of my code: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp There is a list filled by one thread, and a thread that removes the entries after they have been downloaded using curl. The worker-thread waits for a jobs_empty condition and the insertion method calls notify_one after every insertion. Currently the worker-thread just prints "Sitting and waiting", and never reacts on any calls of notifiy_one(). Regards Andreas Pokorny

1 1

BOOST_WORKAROUND in test files?
by Gennaro Prota 26 Jun '04

26 Jun '04

Hi, is it allowed/OK to use BOOST_WORKAROUND in the boost test files? Or should we simply use #if/#ifdef? For instance, Codewarrior 8.3 for Windows has some problems in parsing a function template in dyn_bitset_unit_tests4.cpp. A simple fix, suggested by Howard, is: #ifdef __MWERKS__ // will be: __MWERKS__ && __MWERKS__ <= xxx #pragma parse_func_templ off #endif Should this use BOOST_WORKAROUND? In general: What should compiler/library vendors see when they define BOOST_STRICT_CONFIG? Just errors in the boost headers or errors in the test files too? -- Genny.

2 1

intrusive_ptr: proposal for common base class
by Stefan Slapeta 26 Jun '04

26 Jun '04

Hi all, Sorry if this has been discussed yet, but I think there is an obvious pattern in the usage of intrusive_ptr which should be exposed as common functionality in boost. In most of the cases you just want to handle a simple reference count and delete the object which is held by the intrusive_ptr when the reference count is decreased to zero. It's very annoying that you currently have to write external add_ref/release functions for every class you want to use with this smart pointer. Additionaly, it makes the code unreadable. That's why I would like to suggest having a base class which provides the simplest functionality a user could expect from intrusive_ptr: handling the reference count and deleting the object. A class which should be maintained by intrusive_ptr can derive from it and would not have to provide any further interfaces. I'm not glad about the class name 'intrusive_ptr_base' but I don't have any good ideas at the moment :( Awaiting you comments! (code: see below) Stefan namespace boost { class intrusive_ptr_base; void intrusive_ptr_add_ref(intrusive_ptr_base*); void intrusive_ptr_release(intrusive_ptr_base*); class intrusive_ptr_base { friend void intrusive_ptr_add_ref(intrusive_ptr_base*); friend void intrusive_ptr_release(intrusive_ptr_base*); int ref_count__; protected: intrusive_ptr_base() : ref_count__(0) {} virtual ~intrusive_ptr_base() {} }; inline void intrusive_ptr_add_ref(intrusive_ptr_base* o) { ++o->ref_count__; } inline void intrusive_ptr_release(intrusive_ptr_base* o) { if (--o->ref_count__ == 0) { delete o; } } } // namespace

2 2

Hmmm.. how do I add a new test to the regressions?
by Fernando Cacciola 26 Jun '04

26 Jun '04

I forgot it.... I need to add the Numeric Conversions Library so I can start hunting compiler problems. Fernando Cacciola SciSoft

2 1

RE: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 25 Jun '04

25 Jun '04

Mike, With all due respect I am not sure that the additional complexity you are proposing is justified. It appears that the differences in lock and try_lock default constructors' behavior are consistent with other libraries and actually feel intuitive and natural to me. After all, it is reflected in what I do -- with lock I try until I succeed (that is [Batov, Vladimir] the lock blocks until succeeds), with try_lock I try once and may fail (that is it unconditionally falls through for me to check the result). Best, V. Date: Thu, 24 Jun 2004 14:14:02 -0400 From: Michael Glassford <glassfordm(a)hotmail.com> Subject: [boost] Boost.Threads proposed change: lock constructors To: boost(a)lists.boost.org Message-ID: <cbf5as$hvv$1(a)sea.gmane.org> Content-Type: text/plain; charset=us-ascii; format=flowed Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

2 1

Regression logs oddity
by Gennaro Prota 25 Jun '04

25 Jun '04

Hi everybody, does anyone have hints as to why the Linux regression logs include the first 3 dynamic_bitset test files twice, in two different versions? Example: gcc-3.4.0- linux 3.4.0 ------------------------------------------------------------------- dyn_bitset_unit_tests1 Fail dyn_bitset_unit_tests1 Pass dyn_bitset_unit_tests2 Fail dyn_bitset_unit_tests2 Pass dyn_bitset_unit_tests3 Fail dyn_bitset_unit_tests3 Pass dyn_bitset_unit_tests4 Pass -- Genny.

2 1

dynamic_any campaign?
by fehrin＠t-online.de 25 Jun '04

25 Jun '04

On http://www.cuj.com/boost/ (Boost Corner) the first article is I/O System: dynamic_any campaign by Alexander Nasonov. Is dynamic_any really scheduled for inclusion in boost (1.32 say)? Greetings Franz

3 2

Re:[boost] 1.32 release preparation
by Robert Ramey 25 Jun '04

25 Jun '04

I would very much like to see the serialization library in the 1.32 Release. However, I'm not sure it will be possible to make the posted schedule. I have made all changes to address issues raised in the review. On my personal machine I have passed tests for the compilers VC 7.1 VC 6, gcc 3.3. Borland compiles (almost everything but requires some debug - it will pass most tests) Comeau- compiles everthing - accept for a show stopping problem I've been unable to resolve. My intention has been: a) post version compatible with 1.31 next week. b) build and test against the CVS tree on my computer c) check in In order to do this I need: a) authority to check in b) information on how to mark tests/compilers known to fail. c) I have a couple of questions that I need an expert opinion on. i) the first one is that in order to work, versions for vc 6.0 and borland need to be compiled with spirit 1.61. So the a special environmental variable indicating the directory path where this version of spirit is located on the testing machine. SPIRIT_ROOT. This variable has to be set when serialization libraries are built for these compilers. I should say I'm more than a little bit concerned about changes to mpl and iterators. I'm very much aware of the delays and difficulties associated with the 1.31 release - and it didn't even include this package. So I would like to continue on the path I've established above and we'll see where things stand July 16 when/if you are ready to branch for release. Good Luck ! Robert Ramey

4 4