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

RE: [Boost-users] Threading problem
by Geert Pante 12 Feb '04

12 Feb '04

There's nothing wrong with your runnable class, but with your use of thread::join(). Boost::threads start as soon as they are constructed, join() means: wait until they are finished. In your test code, it doesn't make sense to join() your threads before you Stop() them. Probably the next is what you meant: Threading::boost_thread_starter starter3((Threading::Runnable *)&writer2); boost::thread* _writer_thread2 = new boost::thread(starter3); // pause for 5 secs boost::xtime xt; … [View More]

1 0

Threading problem
by Damien McGivern 12 Feb '04

12 Feb '04

(First post) Hi, I've just started working with boost and have come into some trouble with the thread class. I've included the test code that I'm having the problem with in the hope that someone could point out to me where I'm going wrong. The code tests the QueueAccessor class (CommandQueue.hpp) with the test code in CommandQueueTest.hpp. I created a base class (Runnable) to aid in creating a thread that runs an object's method rather than a function. The code compiles OK and seems to run … [View More]OK too at first until I realised that the main thread has somehow become one of the threads that I created and is in a continuous loop after the first join() is called _writer_thread1->join(); // line 21 As you can probably guess from my code my background is in Java so I'm not entirely sure if I'm using the boost::thread correctly. I tested the QueueAccessor using threads that use a static worker function instead of an object's method and it seemed to run OK so I'm assuming that the problem lies with the Runnable base class. I'm using boost version 1.31.0 running Windows XP and using VS.Net 2003 to compile/run the code. Any help will be very much appreciated Cheers mcgiv ___________________________________________________________ BT Yahoo! Broadband - Free modem offer, sign up online today and save £80 http://btyahoo.yahoo.co.uk #ifndef __TEST_COMMANDQUEUE2__ #define __TEST_COMMANDQUEUE2__ #include <Universal/CommandQueue.hpp> #include <Threading/Runnable.hpp> using namespace Universal; boost::mutex _iomutex; class Worker : public Threading::Runnable { public: Worker(QueueAccessor* q):Threading::Runnable(), _queue(q), _pause_sec(0){} void Run() { while(this->_running) { this->Do(); if(this->_pause_sec > 0) this->Pause(this->_pause_sec); } } virtual void Do() = 0; protected: QueueAccessor* _queue; int _pause_sec; }; class Writer : public Worker { public: Writer(QueueAccessor* q):Worker(q),_index(0){ this->_pause_sec = 2; } void Do() { boost::mutex::scoped_lock scoped_lock(_iomutex); QueueItem item("hi there", this->_index++); this->_queue->Push(item); std::cout << "Add" << std::endl; } short _index; void Stop() { boost::mutex::scoped_lock scoped_lock(_iomutex); this->_running = false;//Threading::Runnable::Stop(); std::cout << "Stopped Writer" << std::endl; } }; class Reader : public Worker { public: Reader(QueueAccessor* q):Worker(q){} void Do() { while(this->_queue->Size() == 0){} boost::mutex::scoped_lock scoped_lock(_iomutex); QueueItem item = this->_queue->Pop(); std::cout << "Removed id=" << item._data_len << " Data=" << item._data << std::endl; } void Stop() { boost::mutex::scoped_lock scoped_lock(_iomutex); this->_running = false;//Threading::Runnable::Stop(); std::cout << "Stopped Reader" << std::endl; } }; void test() { QueueAccessor* q = new QueueAccessor(); Reader reader(q); Writer writer1(q); Writer writer2(q); // set up threads Threading::boost_thread_starter starter((Threading::Runnable *)&reader); boost::thread* _reader_thread = new boost::thread(starter); Threading::boost_thread_starter starter2((Threading::Runnable *)&writer1); boost::thread* _writer_thread1 = new boost::thread(starter2); Threading::boost_thread_starter starter3((Threading::Runnable *)&writer2); boost::thread* _writer_thread2 = new boost::thread(starter3); // start threads _writer_thread1->join(); _writer_thread2->join(); _reader_thread->join(); // pause for 5 secs boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 5; boost::thread::sleep(xt); reader.Stop(); writer1.Stop(); writer2.Stop(); delete q; char c; std::cin >> c; } #endif __TEST_COMMANDQUEUE2__ #ifndef __IRUNNABLE__ #define __IRUNNABLE__ #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> namespace Threading { class Runnable { public: Runnable():_running(true){} virtual void Run() = 0; virtual void Stop(){_running = false;} protected: bool _running; // sleeps thread for x sec void Pause(int sec) { boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += sec; boost::thread::sleep(xt); } void Pause(int sec, int ns) { boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += sec; xt.nsec += ns*1000; boost::thread::sleep(xt); } }; // used to pass the Runnable object to the thread's start function struct boost_thread_starter { boost_thread_starter(Runnable* runnable):_runnable(runnable){} // function is called when boost::thread starts void operator()() { // start the Runnable's run method _runnable->Run(); } Runnable* _runnable; }; }// end Threading namespace #endif // __IRUNNABLE__ #ifndef __COMMANDQUEUE__ #define __COMMANDQUEUE__ #include <boost/thread/mutex.hpp> #include <queue> namespace Universal { struct QueueItem { /* QueueItem(int thread, int value):_thread(thread), _value(value){} int _thread; int _value; //*/ QueueItem(char *data, short data_len):_data(data), _data_len(data_len){} char *_data; short _data_len; //*/ }; // used to sync access to the queue class QueueAccessor { public: QueueAccessor(){} void Push(QueueItem item) { boost::mutex::scoped_lock scoped_lock(_mutex); _queue.push(item); } QueueItem Pop() { boost::mutex::scoped_lock scoped_lock(_mutex); if( _queue.size() > 0 ) { QueueItem tmp = _queue.front(); _queue.pop(); return tmp; } } int Size() { return _queue.size(); } protected: std::queue<QueueItem> _queue; boost::mutex _mutex; }; }// Universal namespace #endif // __COMMANDQUEUE__ [View Less]

1 0

[BGL] adjacency_list: edge_descriptor ordering
by Ded Panas 12 Feb '04

12 Feb '04

Hi boost! How to store edge descriptors in a sorted container? There is no operator< for this type. Is it considered useless? In my graph building code I first build graph structure, and than calculate properties. So I need to remember edge descriptors between that stages... Also, about the docs: there is no link from Table of Contents to AdjacencyMatrix.html, where edge() function is described. TIA dedpanas

1 0

VTL question (sorry if this is slightly off-topic)
by Matt Verona 11 Feb '04

11 Feb '04

Hello, I was reviewing the View Template Library (VTL) - see http://www.zib.de/weiser/vtl/ ... and have a few questions regarding Views as applied to STL Maps. I was also wondering if Boost was planning to eventually provide a VTL-like framework? I'm looking for a type of View that provides read-only access to an STL map, with only const iterators, but also provides limited insertion and removal access as well (as shown below): This new limited View-like map will only allow clients to … [View More]

1 0

[BGL] adjacency_list: OutEdgeList and EdgeList
by Ded Panas 11 Feb '04

11 Feb '04

I'm somewhat unclear about the difference between OutEdgeListS and EdgeListS selectors of adjacency_list. My questions is: 1. Why EdgeListS defaults to listS, while OutEdgeListS to vecS (BTW, doc says that EdgeListS defaults to vecS also) ? 2. In the docs ("Choosing the Edgelist and VertexList"), what is Edgelist: OutEdgeListS or EdgeListS? It is unclear (seems it is OutEdgeListS). TIA dedpanas

2 1

RE: [Boost-users] Re: Re: Thread creation state
by Kutch, Patrick G 11 Feb '04

11 Feb '04

Looking at the code, by 1st guess would be that you have a race condition. tObj->runthread() is getting executed before tObj->createthead() has finished its business and the worker thread has actually entered the mutex. Meaning that tObj->runthread() calls the notify_one() BEFORE the actual worker thread does a wait. Thus when your threadproc does a lock and then a wait, it will wait forever because nothing will do the notify_one() again. Race conditions are funny things, may work … [View More]perfectly on one box forever, then change one line of code, or take it to another system and bad things happen. May also behave differently under different OS's - mutexes are a prime examle of this, under Windows they seem to be recursive by default, but not under LINUX. A down and dirty way to see if my theory is correct, put in a delay between the tObj->createthread() and tObj->runthread() lines. Hope this helps - if it does praise me with thanx, if it doesn't it was a crackpot theory or I haven't had sufficient coffee yet to make an intelligent analysis - you pick. :-) good luck, - Patrick -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, February 11, 2004 7:40 AM To: Boost Users mailing list Subject: [Boost-users] Re: Re: Thread creation state What I meant was, can you post a complete sample that you have actually compiled and run and that has actually demonstrated the problem? That obviously isn't the case with the code you posted because it contains syntax errors and the main() function in your second post doesn't match the definition of the testCommand class in your first post. Having said that, I fixed the errors the best I could and don't see the problem. It would help if you could: 1) Tell me what compiler and compiler version you're using. 2) Tell me what Boost version you're using. 3) Post a complete code sample that demonstrates the problem. 4) Specify what compile and link options you're using (perhaps you could attach a make file or project file?) Sorry; I'm trying to help, but if you want me to be able to figure out the problem you'll have to help me out. Mike ----- Original Message ----- From: <janardhan.guptha(a)efi.com> Newsgroups: gmane.comp.lib.boost.user Sent: Tuesday, February 10, 2004 11:32 PM Subject: RE: Re: Thread creation state > > The rest of the applicatin is just creating the object and preparing it > for execution. I am using Win32 version of boost.Thread implementation. > > The creation code snipet is > > void main() { > testCommand *tObj = new testCommand(11); > tObj->createthread(); > tObj->runthread(); > } > > > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Michael > Glassford > Sent: Wednesday, February 11, 2004 12:17 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Re: Thread creation state > > > It would be a lot easier to help if you could post a complete, > compilable example that demonstrates the problem. Also, it would be > useful to know whether you are using the Win32, pthread, or Mac > implementation of Boost.Thread. > > Thanks, > > Mike > > > <janardhan.guptha(a)efi.com> wrote in message > news:433CFA26BCA852438922F929E3D07955AE53A7@blraddc02.efi.internal... > > I am creating a boost thread, how to know in which state it is > created. > > I have a code snippet that is waiting always in the thread creatin > functon > > istelf. Where as i tried with some boost samples, they are working > amazingly > > perfect. This is how my code snippet looks like > > > > typedef boost::mutex::scoped_lock lock; > > class testCommand { > > static void threadfunc() { > > testCommand *testObj = mMapCommand[mObjID]; > > testObj->processthread(); > > }; > > > > static map< int mObjID, testCommand*> mMapCommand; > > private: > > void createthread() { > > mThread = new boost::thread(&testCommand::threadfunc); > > } > > void processthread() { > > lock lk(mMutex); > > mCondition.wait(lk); > > //// Some Action > > }; > > > > void runthread() { > > lock lk(mMutex); > > mCondition.notify_one(); > > }; > > > > public: > > static int mObjID; > > boost::thread *mThread; > > boost::condition mCondition; > > boost::mutex mMutex; > > }; > > > > > > The newly created thread is waiting at the following location > forever, by > > the time > > i get a chance to execute the new thread is greatly delayed. > > > > NTDLL! 77f8856e() > > boost::detail::thread::lock_ops<boost::mutex>::unlock(boost::mutex & > {...}) > > line 49 > > boost::detail::thread::scoped_lock<boost::mutex>::unlock() line 85 + > 11 > > bytes > > > boost::detail::thread::scoped_lock<boost::mutex>::~scoped_lock<boost:: > mutex> > > () line 74 > > `anonymous namespace'::thread_param::started() line 47 + 15 bytes > > thread_proxy(void * 0x0012fd74) line 71 > > _threadstartex(void * 0x00961040) line 212 + 13 bytes > > KERNEL32! 7c57b382() > > > > It sounds like i am missing something here. The queries here are > > 1. why it is waiting at the above specified line forever ? > > 2. Where can i get few worth thread samples done using boost::thread > > > > Regards > > Janardhan > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users [View Less]

1 0

RE: [Boost-users] Re: Conversions between shared_ptr<Base>andshared_ptr<Derived>
by Ben Hutchings 11 Feb '04

11 Feb '04

Konstantin Baumann <boost(a)ks-baumann.de> wrote: > For performance reasons I would like to see something like the > following conversion operators in shared_ptr<T>: > > template<class T> > class shared_ptr { > public: > ... > template<class S> > operator shared_ptr<S>&() throw() { > BOOST_STATIC_ASSERT(T* is convertible to S*); > return reinterpret_cast<shared_ptr<S>&>(*this); > … [View More]

1 0

RE: [Boost-users] Re: Thread creation state
by janardhan.guptha＠efi.com 11 Feb '04

11 Feb '04

The rest of the applicatin is just creating the object and preparing it for execution. I am using Win32 version of boost.Thread implementation. The creation code snipet is void main() { testCommand *tObj = new testCommand(11); tObj->createthread(); tObj->runthread(); } -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Michael Glassford Sent: Wednesday, February 11, 2004 12:17 AM To: boost-users(a)lists.… [View More]boost.org Subject: [Boost-users] Re: Thread creation state It would be a lot easier to help if you could post a complete, compilable example that demonstrates the problem. Also, it would be useful to know whether you are using the Win32, pthread, or Mac implementation of Boost.Thread. Thanks, Mike <janardhan.guptha(a)efi.com> wrote in message news:433CFA26BCA852438922F929E3D07955AE53A7@blraddc02.efi.internal... > I am creating a boost thread, how to know in which state it is created. > I have a code snippet that is waiting always in the thread creatin functon > istelf. Where as i tried with some boost samples, they are working amazingly > perfect. This is how my code snippet looks like > > typedef boost::mutex::scoped_lock lock; > class testCommand { > static void threadfunc() { > testCommand *testObj = mMapCommand[mObjID]; > testObj->processthread(); > }; > > static map< int mObjID, testCommand*> mMapCommand; > private: > void createthread() { > mThread = new boost::thread(&testCommand::threadfunc); > } > void processthread() { > lock lk(mMutex); > mCondition.wait(lk); > //// Some Action > }; > > void runthread() { > lock lk(mMutex); > mCondition.notify_one(); > }; > > public: > static int mObjID; > boost::thread *mThread; > boost::condition mCondition; > boost::mutex mMutex; > }; > > > The newly created thread is waiting at the following location forever, by > the time > i get a chance to execute the new thread is greatly delayed. > > NTDLL! 77f8856e() > boost::detail::thread::lock_ops<boost::mutex>::unlock(boost::mutex & {...}) > line 49 > boost::detail::thread::scoped_lock<boost::mutex>::unlock() line 85 + 11 > bytes > boost::detail::thread::scoped_lock<boost::mutex>::~scoped_lock<boost:: mutex> > () line 74 > `anonymous namespace'::thread_param::started() line 47 + 15 bytes > thread_proxy(void * 0x0012fd74) line 71 > _threadstartex(void * 0x00961040) line 212 + 13 bytes > KERNEL32! 7c57b382() > > It sounds like i am missing something here. The queries here are > 1. why it is waiting at the above specified line forever ? > 2. Where can i get few worth thread samples done using boost::thread > > Regards > Janardhan _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users [View Less]

2 1

RE: [Boost-users] long compilation time of variant over long typelist with gcc
by Ben Hutchings 11 Feb '04

11 Feb '04

Graeme Lufkin <gwl(a)u.washington.edu> wrote: <snip> > When I compile code that declares a variable of this variant > type, the compilation takes unreasonably long (like, 1.5 hours on a > 2Ghz machine). For fewer types it goes much quicker, the transition > to unreasonably long happens around 14 types in the mpl::vector. <snip> > Something else I've noticed: the Intel compiler doesn't have the > compilation problem! I've attached sample case code that … [View More]

1 0

Spirit: pt_parse doesn't compile when using phrase_scanner_t for rules
by Steve Folly 11 Feb '04

11 Feb '04

Hi, I've read FAQ question number one about the free parse() function not compiling when and I've managed to get that to work by using rule<phrase_scanner_t> as suggested. However, I need to use the pt_parse method to create a parse tree. I'm obviously missing something really obvious because now pt_parse wont compile, even though I'm using a phrase_scanner_t because of the space_p skip parser. Any pointers most welcome. Thanks. Steve.

2 2