- Boost-users - lists.boost.org

RE: [Boost-Users] Boost.Threads question
by James Zappia 05 Dec '02

05 Dec '02

> Thanks for all you help. I have a few new questions now, though. ;) > Again, I'm a newbie to C++ so this may seem stupid... > > I created a boost::thread object and even though it goes out of scope, > the thread continues to run. > >As it should, and as it's well documented. The boost::thread object is >analogous to a std::fstream, where the file doesn't get deleted when the >object goes out of scope. In other words, it's just a handle to the >actual running thread. Understood. > Also, when passing a class with the > operator() defined to boost::thread, it constructs and destructs the > object several times which seems odd. > >Also well documented, and essential. If this didn't occur, you'd have to >insure the lifetime of the object passed was longer than the lifetime of >the thread of execution (not the boost::thread object, the actual thread >of execution). Understood. > What I'm basically trying to do > is run a thread, have that thread lock a timed_mutex, then do its job. > Then, in main, I try to lock the same timed_mutex and if I can't get a > lock before the time expires, I need to terminate the thread. Below is > the source code and the output generated. My questions are below, after > the output. > > SOURCE: > #include <iostream> > #include <boost/thread/xtime.hpp> > #include <boost/thread/thread.hpp> > #include <boost/thread/exceptions.hpp> > > using namespace std; > > boost::timed_mutex mutex; > > class thread_class > { > public: > explicit thread_class(int sleep): _sleep(sleep) {}; > > void operator()() > { > boost::xtime xt; > > cout << "thread: locking mutex\n"; > boost::timed_mutex::scoped_timed_lock lock(mutex,true); > >Why do you continue to use this syntax? This performs an explicit lock, >not a timed lock. This overload is for two use cases: > >1) Creating an unlocked lock object: > >scoped_time_lock lock(mutex, false); > >2) Creating a locked lock object which later will be unlocked and then >locked again through a timed lock: > >scoped_time_lock lock(mutex, true); >// .. some code >lock.unlock(); >// .. some code >if (lock.timed_lock()) { > // .. some code >} > >Obviously the second use case will be extremely rare. In your case you're >doing neither of these, and you'd be better served just using a simple >scoped_lock. > > boost::xtime_get(&xt,boost::TIME_UTC); > > cout << "thread: sleeping for " << _sleep << " seconds\n"; > > xt.sec += _sleep; > boost::thread::sleep(xt); > > cout << "thread: freeing lock -- goodbye\n"; > } > > ~thread_class() { cout << "thread_class destructed\n"; } > > private: > int _sleep; > }; > > int main( void ) > { > { > cout << "main: creating thread\n"; > > thread_class test(10); > boost::thread thrd(test); > > cout << "main: sleeping for 2 seconds\n"; > sleep(2); > > cout << "main: trying to lock mutex -- waiting 5 > seconds...\n"; > > boost::timed_mutex::scoped_timed_lock lock(mutex,false); > > boost::xtime xt; > boost::xtime_get(&xt,boost::TIME_UTC); > xt.sec += 5; > > if ( lock.timed_lock(xt) ) > { > cout << "obtain lock -- joining thread\n"; > thrd.join(); > } > else > { > cout << "failed to obtain lock\n"; > } > } > >I'd code this as: > >boost::xtime xt; >boost::xtime_get(&xt, boost::TIME_UTC); >xt.sec += 5; >boost::timed_mutex::scoped_time_lock lock(mutex); >if (lock) // or if (lock.locked()) >{ >// etc I assume you mean boost::timed_mutex::scoped_timed_lock lock(mutex,xt) because I don't see a constructor that takes only a timed_mutex. That said, I agree that your way of doing it is better. Above you asked why I continue to use the syntax I do for locking the mutex in the thread. I want to immediately lock it, then in the main thread try to lock it for a finite amount of time. I can't do that with scoped_lock. Perhaps my strategy is wrong. I want to run a thread for only a specified amount of time. I can't afford to block on a join() to wait for that thread to finish. > cout << "main: making sure thread is gone\n"; > >That's what join is for. I realize this is a toy example, but I can't see >a valid reason for coding it this way. All you've done is introduce race >conditions, even if they are conditions you can feel fairly confident will >do what you want. > > sleep(10); > > return 0; > } > > OUTPUT: > main: creating thread > thread_class destructed > thread_class destructed > thread_class destructed > thread_class destructed > main: sleeping for 2 seconds > thread: locking mutex > thread: sleeping for 10 seconds > main: trying to lock mutex -- waiting 5 seconds... > failed to obtain lock > thread_class destructed > main: making sure thread is gone > thread: freeing lock -- goodbye > thread_class destructed > > 1) Why are so many thread_class objects constructed/destructed when > calling boost::thread? > >The number surprises me a little. I'd have expected two copies, knowing >what I do about the implementation and with out carefully evaluating the >code here. But the documentation is clear that the object will be copied >AT LEAST once, and is free to copy the object any number of times. You >need to account for this in your implementation if it matters. Understood. Apologies for not thoroughly reading the doc first. > 2) After the thread object (test) goes out of scope, why does the thread > continue to run? Is it copied when calling boost::thread and run > detached from the main thread? > >I don't know what you mean by "run detached from the main thread", but >yes, test IS copied (but then, you know that based on what you asked in >1). But then, maybe you meant something else. The "thread object" is >actually "thrd" in your code above, not "test". > > 3) Is there a way I can cancel a thread if going out of scope doesn't > stop it? > >Not yet, but there will be. However, I'm not sure that what you want to >do is really to cancel the thread. It's hard to tell from this toy >example. What the application does is run a job (thread) that has a finite amount of time to finish. If it doesn't finish in that time it needs to send an alert and explicitly terminate the thread (because it can't be blocked with a join() unless it knows the thread is done). As stated above, perhaps my strategy of using the mutex to see if a thread ran in a given amount of time is wrong. Hopefully I'm making some sense, if not, I apologies. James >William E. Kempf Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

ublas::matrix debugging values
by Nick Toze 05 Dec '02

05 Dec '02

Hello, I'm using ublas in MSVC6. How do I find out the values of elements of a matrix when debugging? If I try putting for example mat[0][0] in the 'watch' window then it says 'CXX0058: Error: overloaded operator not found'. Thanks in advance, Nick

1 0

[Fwd: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.29.0]
by William E. Kempf 05 Dec '02

05 Dec '02

I'm not sure if _XOPEN_SOURCE or _GNU_SOURCE are defined by the configuration headers or not. It does sound to me, however, like things may well be working on Linux properly and we might just have a user error. Again, can I get a test case for this in order to verify precisely what's wrong? Bill Kempf -------- Original Message -------- Subject: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.29.0 From: Dan Nuffer <dnuffer(a)sco.com> Date: Thu, December 5, 2002 10:02 am To: wekempf(a)cox.net Hmm, seems yahoogroups won't let me send an e-mail to boost-users, I guess I subscribed with a different e-mail addr, so I'll just send this directly to you. Subject: Re: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.2 9.0 From: Dan Nuffer <dnuffer(a)sco.com> Date: Wed, 04 Dec 2002 17:13:15 -0700 To: Boost-Users(a)yahoogroups.com William E. Kempf wrote: >> Hi >> >> I experienced a lot of deadlocking situations when I used >> recursive_mutex on SuSE Linux 8.1. When I analysed this mutex code I found out, that the implementation of recursive_mutex on Linux is based on recursive POSIX mutexes (set with pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)). Things were getting interesting when I didn't find a man page for this function and I started to suspect Linux not having implemented this mutex type. >> >> The next thing I had done was to disable recursive POSIX mutexes by commenting out the line "#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE" in the file boost_1_29_0/boost/config/posix_features.hpp" forcing boost to implement recursive_mutex by itself. > > > > Interestingly enough, the manpages indicate that Linux has a > pthread_mutexattr_setkind_np that does the same thing as > pthread_mutexattr_settype. I'm not a POSIX programmer, so I'm feeling my way around blindly with some of these more esoteric optional and/or new features. I'm not sure how to correctly detect the availability here, and > to configure accordingly. I'll have to research this particular case for a fix. If anyone knows how to fix the configuration here, please speak up. > Linux definitely has the required functions/functionality. See http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/mutex.c?rev=… However, in the pthread.h header, the stuff is inside of: #ifdef __USE_UNIX98 To activate it, you should #define _XOPEN_SOURCE 500 or #define _GNU_SOURCE before you actually include anything (best to use -D cmd line arg). > One thing that confuses me... how does this even compile on Linux? If the > pthread_mutexattr_settype function is available to the compiler/linker, why on earth would it not function properly? Definately need to do some research. > > Also, if you have a simple test case that reproduces the deadlock it would > be beneficial for you to send it to me for addition to the test harness. > > >> Since then everything is working quite perfectly! >> >> But I'd like to raise some questions: >> * Is my assumption correct that Linux doesn't have a proper support for recursive POSIX mutexes? > > > > It has support, evidently, possibly just not "proper" support. (Or maybe it does have proper support that's just not documented and we have an implementation problem on my end?) > Linux's implementation looks okay to me. However, it not documented in the man pages. If you have any other questions or anything I can help you out with wrt Linux, just let me know. --Dan William E. Kempf Booster (http://www.boost.org) Boost.Threads author

1 0

Deadlocking problems with recursive_mutex on Linux with boost 1.2 9.0
by beat.schaer＠ruag.com 05 Dec '02

05 Dec '02

Hi I experienced a lot of deadlocking situations when I used recursive_mutex on SuSE Linux 8.1. When I analysed this mutex code I found out, that the implementation of recursive_mutex on Linux is based on recursive POSIX mutexes (set with pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)). Things were getting interesting when I didn't find a man page for this function and I started to suspect Linux not having implemented this mutex type. The next thing I had done was to disable recursive POSIX mutexes by commenting out the line "#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE" in the file boost_1_29_0/boost/config/posix_features.hpp" forcing boost to implement recursive_mutex by itself. Since then everything is working quite perfectly! But I'd like to raise some questions: * Is my assumption correct that Linux doesn't have a proper support for recursive POSIX mutexes? * Can I expect that this problem will be solved in a future release of boost? Regards Beat

3 3

RE: [Boost-Users] Boost.Threads question
by James Zappia 05 Dec '02

05 Dec '02

> Thank you, that worked. I see what I was doing wrong. > > One thing I don't understand about the alternative method... > >> boost::try_mutex::scoped_try_lock lock(mutex); // does a try_lock >> while (!lock) { >> cout << "trying..."; >> lock.try_lock(); >> } > > How does "!lock" in the "while (!lock) { ... }" statement determine > whether it's true or false? Does it call a function in the > scoped_try_lock class? (sorry if that's a lame question...) >Hmmm... this doesn't seem to be documented very well. I'll have to fix >that. What it does is invoke operator void*() for a boolean test (this >mechanism also should be updated to use the safe_bool idiom as well). >Alternatively, you could call lock.locked() (which also appears to be >poorly documented). Thanks for pointing out these deficiencies. >William E. Kempf Thanks for all you help. I have a few new questions now, though. ;) Again, I'm a newbie to C++ so this may seem stupid... I created a boost::thread object and even though it goes out of scope, the thread continues to run. Also, when passing a class with the operator() defined to boost::thread, it constructs and destructs the object several times which seems odd. What I'm basically trying to do is run a thread, have that thread lock a timed_mutex, then do its job. Then, in main, I try to lock the same timed_mutex and if I can't get a lock before the time expires, I need to terminate the thread. Below is the source code and the output generated. My questions are below, after the output. SOURCE: #include <iostream> #include <boost/thread/xtime.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/exceptions.hpp> using namespace std; boost::timed_mutex mutex; class thread_class { public: explicit thread_class(int sleep): _sleep(sleep) {}; void operator()() { boost::xtime xt; cout << "thread: locking mutex\n"; boost::timed_mutex::scoped_timed_lock lock(mutex,true); boost::xtime_get(&xt,boost::TIME_UTC); cout << "thread: sleeping for " << _sleep << " seconds\n"; xt.sec += _sleep; boost::thread::sleep(xt); cout << "thread: freeing lock -- goodbye\n"; } ~thread_class() { cout << "thread_class destructed\n"; } private: int _sleep; }; int main( void ) { { cout << "main: creating thread\n"; thread_class test(10); boost::thread thrd(test); cout << "main: sleeping for 2 seconds\n"; sleep(2); cout << "main: trying to lock mutex -- waiting 5 seconds...\n"; boost::timed_mutex::scoped_timed_lock lock(mutex,false); boost::xtime xt; boost::xtime_get(&xt,boost::TIME_UTC); xt.sec += 5; if ( lock.timed_lock(xt) ) { cout << "obtain lock -- joining thread\n"; thrd.join(); } else { cout << "failed to obtain lock\n"; } } cout << "main: making sure thread is gone\n"; sleep(10); return 0; } OUTPUT: main: creating thread thread_class destructed thread_class destructed thread_class destructed thread_class destructed main: sleeping for 2 seconds thread: locking mutex thread: sleeping for 10 seconds main: trying to lock mutex -- waiting 5 seconds... failed to obtain lock thread_class destructed main: making sure thread is gone thread: freeing lock -- goodbye thread_class destructed 1) Why are so many thread_class objects constructed/destructed when calling boost::thread? 2) After the thread object (test) goes out of scope, why does the thread continue to run? Is it copied when calling boost::thread and run detached from the main thread? 3) Is there a way I can cancel a thread if going out of scope doesn't stop it? Thanks again, James Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

boost::function and template member functions
by Markus Werle 05 Dec '02

05 Dec '02

Hi! With the help of ConcreteEvoker I was able to get an (indirect) address for Test::Apply<double>. This address is obtained via automatic template instantiation, so I feel like there must be a way to achiev the same thing without ConcreteEvoker. Any comments? #include <iostream> #include "boost/function.hpp" #include "boost/bind.hpp" struct Test { template <class T> static T Apply(T t1, T t2) { return t1 + t2; } }; template <class T, class OP> struct ConcreteEvoker { static T Apply(T d1, T d2) { return OP::Apply(d1, d2); } }; int main() { boost::function<double (double, double)> test = &ConcreteEvoker<double, Test>::Apply; std::cerr << test(1.0, 2.0) << std::endl; }

2 1

to add a function to the BGL
by Ramón Casero Cañas 05 Dec '02

05 Dec '02

Let's say I've written a function to prune edges of a graph (data structures and methods are those of the BGL), in the typical C-way (declare the function header in a .h file, and write the code in the .c file). Ok, it works, but I'm not fully satisfied. I would like to make it more BGL-like. So I use templates for generic graphs, include concept check lines in my code, and I have to forget about the .h and .c style, as templates behave a little like macros, and you cannot split the declaration and definition in two files. But, is there a better way to do this, like when you add you own internal property to the graph with BOOST_INSTALL_PROPERTY? Regards, Ramón.

1 0

object_pool use ordered_malloc ordered_free. why?
by wugui 05 Dec '02

05 Dec '02

boost_1_28_0 if construct only, and freeall in ~object_pool. i think it is good. can i use object_pool to replace 'new delete'? the destroy is slow. thank for any advice. newbie and not good at english. full test code: #include <boost/pool/object_pool.hpp> #include <vector> #include <iostream> #include <time.h> #include <stdlib.h> struct Some { std::string ss; int ii; char cc[32]; }; int main(int argc, char * argv[]) { boost::object_pool<Some> pool; std::vector<Some*> v_Some; int count = 20000; time_t t = time(0); std::cout << ctime(&t) << std::endl; for (int i=0; i<count; ++i) { Some * s = pool.construct(); if (s) v_Some.push_back(s); else break; } t = time(0); std::cout << v_Some.size() << ctime(&t) << std::endl; if (argc > 1) { // fast for (std::vector<Some*>::reverse_iterator it = v_Some.rbegin(); it != v_Some.rend(); ++it) pool.destroy(*it); } else { // slow for (std::vector<Some*>::iterator it = v_Some.begin(); it != v_Some.end(); ++it) pool.destroy(*it); } t = time(0); std::cout << ctime(&t) << std::endl; return 0; }

1 0

RE: [Boost-Users] Boost.Threads question
by James Zappia 04 Dec '02

04 Dec '02

Thank you, that worked. I see what I was doing wrong. One thing I don't understand about the alternative method... > boost::try_mutex::scoped_try_lock lock(mutex); // does a try_lock > while (!lock) { > cout << "trying..."; > lock.try_lock(); > } How does "!lock" in the "while (!lock) { ... }" statement determine whether it's true or false? Does it call a function in the scoped_try_lock class? (sorry if that's a lame question...) Thanks again for the help, very much appreciated. James Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

RE: [Boost-Users] Boost.Threads question
by James Zappia 04 Dec '02

04 Dec '02

> I'm a newbie to C++ and Boost and I'm trying to port a threaded C > program I have to Boost.Threads. I'm trying to use scoped_try_lock to > test a lock on mutex and it's not working. I'm obviously doing > something wrong but I can't figure it out. Below is the source code. > Any help would be greatly appreciated. >>How is it not working? What do you expect to happen? What I want to happen is that the main thread keeps trying the lock until it's freed. > SOURCE: > > #include <iostream> > #include <boost/thread/thread.hpp> > #include <boost/thread/exceptions.hpp> > > using namespace std; > > boost::try_mutex mutex; > > void thread_test( void ) > { > cout << "thread: locking mutex\n"; > > { > boost::try_mutex::scoped_try_lock lock(mutex); > cout << "thread: sleeping for 10 seconds\n"; > sleep(10); > } > > cout << "thread: unlocked mutex - goodbye!\n"; > > return; > } > > int main( void ) > { > cout << "main: creating thread\n"; > boost::thread thread(thread_test); > > cout << "main: sleeping for 2 seconds\n"; > sleep(2); > > cout << "main: trying to lock mutex\n"; > boost::try_mutex::scoped_try_lock lock(mutex,true); >>This will force a lock (which means we'll block until the thread releases >>the lock). > while ( !lock.try_lock() ) >>Since the above insured the mutex is already locked, this would be a >>recursive lock which should result in a thread_lock_error exception being >>thrown. Is this not what's happening for you? That is what's happening. As stated above, what I would like to happen is the main thread continuously try the lock until it's freed. What am I doing wrong? Thanks for the help! James > cout << "main: retrying to lock mutex\n"; > > cout << "main: joining thread\n"; > thread.join(); > > cout << "main: thread joined\n"; > return 0; > } >>William E. Kempf Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1