- Boost-users - lists.boost.org

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

Boost.Threads question
by James Zappia 04 Dec '02

04 Dec '02

Hi, 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. Thanks, James 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); while ( !lock.try_lock() ) cout << "main: retrying to lock mutex\n"; cout << "main: joining thread\n"; thread.join(); cout << "main: thread joined\n"; return 0; }

2 1