November 2006 - Boost-users

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Goroll, Torsten 07 Nov '06

07 Nov '06

Hi, thank you all for your help. It was a basically missunderstanding of join() on my side. The message of Nat Goodspeed helped me to discover that. So, lets close this thread. Torsten -----Ursprüngliche Nachricht----- Von: Ovanes Markarian [mailto:om_boost@keywallet.com] Gesendet: Dienstag, 7. November 2006 00:29 An: boost-users(a)lists.boost.org Betreff: Re: [Boost-users] [Threads] Problem with starting a sub thread An additional approach could be a thread group, which can create a bunch of threads. Than you can call join on entire group, where the caller thread blocks until all threads are finished. -----Original Message----- From: Nat Goodspeed [mailto:ngoodspeed@solidworks.com] Sent: Monday, November 06, 2006 5:57 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[Serialization] Need help resolving problem putting serialization code into static library
by Mark Melton 07 Nov '06

07 Nov '06

All, I am hoping someone can help me resolve a problem I am having putting serialization code into a static library. If I am lucky, it will be simple user error. Here is a quick synopsis of the code: a.hpp class A { virtual ~A() { } ...} b.hpp class B : public A { virtual ~B() { } ... } with classes A and B both having the standard serialization functions defined in a.cpp and b.cpp respectively along with the necessary BOOST_CLASS_EXPORT statements. Now, compiling a single program like this works fine and the program is able to serialize objects of types A and B through pointers of type A without any problems. Life is good. g++ -o my_prog my_prog.cpp a.cpp b.cpp -lboost_serialization However, compiling a static library and then linking the same program like this produces a my_prog that gets an unregistered_class exception when trying to serialize an object of type B through a pointer of type A. Not what I expected because the only difference is in the linking phase where code is now coming from the library instead of the object files. g++ -o a.o -c a.cpp g++ -o b.o -c b.cpp ar cru a.o b.o libmine.a ranlib libmine.a g++ -o my_prog my_prog.cpp libmine.a -lboost_serialization Now, combining a.cpp and b.cpp and building the library produces a working program. Confusion reigns. g++ -o ab.o -c a.cpp b.cpp ar cru ab.o libmine.a ranlib libmine.a g++ -o my_prog my_prog.cpp libmine.a -lboost_serialization Any ideas would be greatly appreciated. I have tried several incantations, but I cannot make any headway. I am working under the assumptions that it has something do to with the initialization code difference between using the object files and the library. I am using boost 1.33.1 on intel OS X 10.4.8 with g++ in 64 bit mode. If it would be useful, I can run experiments in 32 bit mode or on Ubuntu, but I have yet to find any differences with this issue. Thanks, mark

2 1

Global Mutex
by Daher 07 Nov '06

07 Nov '06

Hi, How do I create a global mutex in boost.threads ? Dee

3 3

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Ovanes Markarian 06 Nov '06

06 Nov '06

An additional approach could be a thread group, which can create a bunch of threads. Than you can call join on entire group, where the caller thread blocks until all threads are finished. -----Original Message----- From: Nat Goodspeed [mailto:ngoodspeed@solidworks.com] Sent: Monday, November 06, 2006 5:57 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Goroll, Torsten 06 Nov '06

06 Nov '06

Thanks for the quick answers. I understood and experienced that the main thread blocks. But how can it join other threads, if it is blocked? That doesn't seem consistent to me. Torsten > > > Hi! > > join cause a calling thread to block until the second one is finished. This is also stated in the > docs: > 1.void join(); > Requires: *this is joinable. > !!!!!Effects: The current thread of execution blocks until the initial function of the thread of > execution represented by *this finishes and all resources are reclaimed. > Notes: If *this == thread() the result is implementation-defined. If the implementation > doesn't detect this the result will be deadlock.

2 1

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Nat Goodspeed 06 Nov '06

06 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other.

1 0

Compiling error in windows VC8: unrecognized posix_time:: microsec_clock
by Cheng, Victor S 06 Nov '06

06 Nov '06

I'm testing the boost 1_33_1 date_time library, but run into a strange compilation problem. In the following code, second_clock::local_time() is fine, but microsec_clock::local_time() will not compile. I'm using XP and visual studio 2005 and VC8. Am I missing anything in my build? compiler messages: 1>.\t2.cpp(18) : error C2653: 'microsec_clock' : is not a class or namespace name 1>.\t2.cpp(18) : error C3861: 'local_time': identifier not found the code: #include "boost/date_time/posix_time/posix_time.hpp" #include <iostream> int main() { using namespace boost::posix_time; ptime now = microsec_clock::local_time(); std::cout << now << std::endl; return 0; } ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

3 2

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Ovanes Markarian 06 Nov '06

06 Nov '06

Hi! join cause a calling thread to block until the second one is finished. This is also stated in the docs: 1.void join(); Requires: *this is joinable. !!!!!Effects: The current thread of execution blocks until the initial function of the thread of execution represented by *this finishes and all resources are reclaimed. Notes: If *this == thread() the result is implementation-defined. If the implementation doesn't detect this the result will be deadlock. There is a good article on boost threads at Dr.Dobbs site: http://www.ddj.com/dept/cpp/184401518 With Kind Regards, Ovanes Markarian On Mon, November 6, 2006 14:17, Torsten wrote: > Hi, > > im trying to initiate a sub thread for checking some variables during the main program is running: > > ...do sth... > > boost::thread checkT(&check); > checkT.join(); > > ...do sth... > > As I understand boost::threads the second "do sth" should be performed during the thread is running. Well, it doesn't seem so. After experimenting some time it came up that starting two threads like that: > > boost::thread checkT(&check); > boost::thread stopCheckT(&stopCheck); > checkT.join(); > scheckT.join(); > > does work, but that: > > boost::thread checkT(&check); > checkT.join(); > boost::thread stopCheckT(&stopCheck); > scheckT.join(); > > does not. I really don't understand why. Either .join() stops executing the code (so the scheckT.join() in the first example shouldn't be called) or it doesn't (than the second scheckT should be called too). > > Where am I wrong? Has anybody an idea? > > Torsten > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > With Kind Regards, Ovanes Markarian

1 0

[Threads] Problem with starting a sub thread
by Torsten 06 Nov '06

06 Nov '06

Hi, im trying to initiate a sub thread for checking some variables during the main program is running: ...do sth... boost::thread checkT(&check); checkT.join(); ...do sth... As I understand boost::threads the second "do sth" should be performed during the thread is running. Well, it doesn't seem so. After experimenting some time it came up that starting two threads like that: boost::thread checkT(&check); boost::thread stopCheckT(&stopCheck); checkT.join(); scheckT.join(); does work, but that: boost::thread checkT(&check); checkT.join(); boost::thread stopCheckT(&stopCheck); scheckT.join(); does not. I really don't understand why. Either .join() stops executing the code (so the scheckT.join() in the first example shouldn't be called) or it doesn't (than the second scheckT should be called too). Where am I wrong? Has anybody an idea? Torsten

2 1

dynamic-bitset: reversing bits.
by chun ping wang 06 Nov '06

06 Nov '06

Hey i have a quick question regarding dynamic bits. Is there a quick and effective way to reverse bits. (if so how)... i try swapping.. but i get compile time error. so that i can calculate iterative-fft since it requires bit-reverse-copy for (i = 0; i<num_bits/2; ++i) swap(b[i], b[i+numbits/2]);

3 2