[1.40.0] Compilation errors in Visual Studio
I experienced compilation problems with Boost 1.40. I am using Visual Studio 2005 and 2008. On both Boost compiles and links fine but is unusable in other code due to compilation errors. Currently I have access to errors produced on 2008 and it would be troublesome to get errors for 2005 (but if needed I will do it) - however the are the same (as to the message): 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template and so on... It is hard for me to tell which header causes the error but if requested I will look for this. 1.39 was just fine in both environments. The external (non-Boost) code did not change in the mean time. Any help? Adam Badura
Hi there I just found that message_queue::receive() or message_queue:: timed_receive () consume high CPU resource, (99% CPU) the code like the below: //create message_queue date d(2009,Sep,8); //an arbitrary date //construct a time by adding up some durations durations ptime t1(d, hours(0)+minutes(0)+seconds(1)+millisec(0)); while (1) { for(int i = 0; i < 100; ++i){ int number; //mq.receive(&number, sizeof(number), recvd_size, priority); mq.timed_receive(&number, sizeof(number), recvd_size, priority,t1); } } As I know, both the receive() & timed_receive() are block method, there should be sleep mechanism inside. why it still need so much CPU resource? Thanks jon
Hi, ----- Original Message ----- From: <jon_zhou@agilent.com> To: <boost@lists.boost.org>; <jon_zhou@agilent.com> Sent: Tuesday, September 08, 2009 4:20 AM Subject: [boost] [interprocess]why message_queue receive() will consume somuch CPU resource
Hi there
I just found that message_queue::receive() or message_queue:: timed_receive () consume high CPU resource, (99% CPU) the code like the below:
//create message_queue
date d(2009,Sep,8); //an arbitrary date //construct a time by adding up some durations durations ptime t1(d, hours(0)+minutes(0)+seconds(1)+millisec(0));
while (1) { for(int i = 0; i < 100; ++i){ int number; //mq.receive(&number, sizeof(number), recvd_size, priority); mq.timed_receive(&number, sizeof(number), recvd_size, priority,t1); } }
As I know, both the receive() & timed_receive() are block method, there should be sleep mechanism inside. why it still need so much CPU resource?
Just a question, What your code does other than calling mq.timed_receive()? Reagrds, Vicente
Hi Some message handle routine were skipped.. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of vicente.botet Sent: Tuesday, September 08, 2009 2:07 PM To: boost@lists.boost.org Subject: Re: [boost] [interprocess]why message_queue receive() will consumesomuch CPU resource Hi, ----- Original Message ----- From: <jon_zhou@agilent.com> To: <boost@lists.boost.org>; <jon_zhou@agilent.com> Sent: Tuesday, September 08, 2009 4:20 AM Subject: [boost] [interprocess]why message_queue receive() will consume somuch CPU resource
Hi there
I just found that message_queue::receive() or message_queue:: timed_receive () consume high CPU resource, (99% CPU) the code like the below:
//create message_queue
date d(2009,Sep,8); //an arbitrary date //construct a time by adding up some durations durations ptime t1(d, hours(0)+minutes(0)+seconds(1)+millisec(0));
while (1) { for(int i = 0; i < 100; ++i){ int number; //mq.receive(&number, sizeof(number), recvd_size, priority); mq.timed_receive(&number, sizeof(number), recvd_size, priority,t1); } }
As I know, both the receive() & timed_receive() are block method, there should be sleep mechanism inside. why it still need so much CPU resource?
Just a question, What your code does other than calling mq.timed_receive()? Reagrds, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The code can trap in sched_yield (),(see below) why it still consume high CPU resource? (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x401b706c in sched_yield () from /lib/tls/libc.so.6 #2 0x0804e88f in thread_yield () at ../boost138inst/include/boost-1_38/boost/interprocess/detail/os_thread_functions.hpp:1 04 #3 0x0804c22b in boost::interprocess::interprocess_condition::do_timed_wait ( this=0x40018018, tout_enabled=false, abs_time=@0xbff77a70, mut=@0x40018014) at ../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond ition.hpp:125 #4 0x0804bfc2 in boost::interprocess::interprocess_condition::do_wait (this=0x40018018, mut=@0x40018014) at ../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond ition.hpp:70 -----Original Message----- From: ZHOU,JON (A-China,ex2) Sent: Tuesday, September 08, 2009 10:21 AM To: boost@lists.boost.org; ZHOU,JON (A-China,ex2) Subject: [interprocess]why message_queue receive() will consume so much CPU resource Hi there I just found that message_queue::receive() or message_queue:: timed_receive () consume high CPU resource, (99% CPU) the code like the below: //create message_queue date d(2009,Sep,8); //an arbitrary date //construct a time by adding up some durations durations ptime t1(d, hours(0)+minutes(0)+seconds(1)+millisec(0)); while (1) { for(int i = 0; i < 100; ++i){ int number; //mq.receive(&number, sizeof(number), recvd_size, priority); mq.timed_receive(&number, sizeof(number), recvd_size, priority,t1); } } As I know, both the receive() & timed_receive() are block method, there should be sleep mechanism inside. why it still need so much CPU resource? Thanks jon
Hi there: I think the "sched_yield" will put itself to the end of the waiting queue If there is no other waiting task, the program will be scheduled again soon. Which is the better way to receive msg? #1 While (1) { Mq.receive(...) } Or #2 While (1) { if (!Mq.try_receive()) sleep(xx) } I think the former can get the best throughput performance but the latter can get the less resource used. Any comments? Thanks Jon -----Original Message----- From: ZHOU,JON (A-China,ex2) Sent: Tuesday, September 08, 2009 9:55 PM To: ZHOU,JON (A-China,ex2); 'boost@lists.boost.org' Subject: RE: [interprocess]why message_queue receive() will consume so much CPU resource The code can trap in sched_yield (),(see below) why it still consume high CPU resource? (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x401b706c in sched_yield () from /lib/tls/libc.so.6 #2 0x0804e88f in thread_yield () at ../boost138inst/include/boost-1_38/boost/interprocess/detail/os_thread_functions.hpp:1 04 #3 0x0804c22b in boost::interprocess::interprocess_condition::do_timed_wait ( this=0x40018018, tout_enabled=false, abs_time=@0xbff77a70, mut=@0x40018014) at ../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond ition.hpp:125 #4 0x0804bfc2 in boost::interprocess::interprocess_condition::do_wait (this=0x40018018, mut=@0x40018014) at ../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond ition.hpp:70 -----Original Message----- From: ZHOU,JON (A-China,ex2) Sent: Tuesday, September 08, 2009 10:21 AM To: boost@lists.boost.org; ZHOU,JON (A-China,ex2) Subject: [interprocess]why message_queue receive() will consume so much CPU resource Hi there I just found that message_queue::receive() or message_queue:: timed_receive () consume high CPU resource, (99% CPU) the code like the below: //create message_queue date d(2009,Sep,8); //an arbitrary date //construct a time by adding up some durations durations ptime t1(d, hours(0)+minutes(0)+seconds(1)+millisec(0)); while (1) { for(int i = 0; i < 100; ++i){ int number; //mq.receive(&number, sizeof(number), recvd_size, priority); mq.timed_receive(&number, sizeof(number), recvd_size, priority,t1); } } As I know, both the receive() & timed_receive() are block method, there should be sleep mechanism inside. why it still need so much CPU resource? Thanks jon
I think this is best dealt with by the OS. On Wed, Sep 9, 2009 at 9:40 PM, <jon_zhou@agilent.com> wrote:
Hi there:
I think the "sched_yield" will put itself to the end of the waiting queue If there is no other waiting task, the program will be scheduled again soon.
Which is the better way to receive msg?
#1 While (1) { Mq.receive(...) }
Or #2 While (1) { if (!Mq.try_receive()) sleep(xx) }
I think the former can get the best throughput performance but the latter can get the less resource used.
Any comments?
Thanks Jon
-----Original Message----- From: ZHOU,JON (A-China,ex2) Sent: Tuesday, September 08, 2009 9:55 PM To: ZHOU,JON (A-China,ex2); 'boost@lists.boost.org' Subject: RE: [interprocess]why message_queue receive() will consume so much CPU resource
The code can trap in sched_yield (),(see below)
why it still consume high CPU resource?
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x401b706c in sched_yield () from /lib/tls/libc.so.6 #2 0x0804e88f in thread_yield () at ../boost138inst/include/boost-1_38/boost/interprocess/detail/os_thread_functions.hpp:1 04 #3 0x0804c22b in boost::interprocess::interprocess_condition::do_timed_wait ( this=0x40018018, tout_enabled=false, abs_time=@0xbff77a70, mut=@0x40018014) at ../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond ition.hpp:125 #4 0x0804bfc2 in boost::interprocess::interprocess_condition::do_wait (this=0x40018018, mut=@0x40018014) at ../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond ition.hpp:70
-----Original Message----- From: ZHOU,JON (A-China,ex2) Sent: Tuesday, September 08, 2009 10:21 AM To: boost@lists.boost.org; ZHOU,JON (A-China,ex2) Subject: [interprocess]why message_queue receive() will consume so much CPU resource
Hi there
I just found that message_queue::receive() or message_queue:: timed_receive () consume high CPU resource, (99% CPU) the code like the below:
//create message_queue
date d(2009,Sep,8); //an arbitrary date //construct a time by adding up some durations durations ptime t1(d, hours(0)+minutes(0)+seconds(1)+millisec(0));
while (1) { for(int i = 0; i < 100; ++i){ int number; //mq.receive(&number, sizeof(number), recvd_size, priority); mq.timed_receive(&number, sizeof(number), recvd_size, priority,t1); } }
As I know, both the receive() & timed_receive() are block method, there should be sleep mechanism inside. why it still need so much CPU resource?
Thanks jon
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, If you are using windows, the message queue uses an emulated mutex / condition ( which is basic a spin lock with Sleep (0) ). It should not use 99% of CPU if you are waiting only one queue, but it may be a problem when you a thousand queues. I think the best approach in windows would be using NamedEvent, and keep the name of the event in shared memory, and when any process attach to it, the initialization fuction would open the named event. In POSIX OS, it uses the boost::ipc::mutex and condition to synchronize the queues. But the boost::ipc::mutex/condition only uses the pthread_mutex / pthread_condition if your posix version supports mutex/condition in shared memory. In case of your posix version does not support it, the boost::ipc::mutex/condition uses an emulated mutex/condition ( spin lock and sched_yeld()), which will lead your program to use 100% of the CPU. regards, Rodrigo Pinho Pereira de Souza On Thu, Sep 10, 2009 at 5:42 AM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
I think this is best dealt with by the OS.
On Wed, Sep 9, 2009 at 9:40 PM, <jon_zhou@agilent.com> wrote:
Hi there:
I think the "sched_yield" will put itself to the end of the waiting queue If there is no other waiting task, the program will be scheduled again soon.
Which is the better way to receive msg?
#1 While (1) { Mq.receive(...) }
Or #2 While (1) { if (!Mq.try_receive()) sleep(xx) }
I think the former can get the best throughput performance but the latter can get the less resource used.
Any comments?
Thanks Jon
-----Original Message----- From: ZHOU,JON (A-China,ex2) Sent: Tuesday, September 08, 2009 9:55 PM To: ZHOU,JON (A-China,ex2); 'boost@lists.boost.org' Subject: RE: [interprocess]why message_queue receive() will consume so much CPU resource
The code can trap in sched_yield (),(see below)
why it still consume high CPU resource?
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x401b706c in sched_yield () from /lib/tls/libc.so.6 #2 0x0804e88f in thread_yield () at
../boost138inst/include/boost-1_38/boost/interprocess/detail/os_thread_functions.hpp:1
04 #3 0x0804c22b in boost::interprocess::interprocess_condition::do_timed_wait ( this=0x40018018, tout_enabled=false, abs_time=@0xbff77a70, mut=@0x40018014) at
../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond
ition.hpp:125 #4 0x0804bfc2 in boost::interprocess::interprocess_condition::do_wait (this=0x40018018, mut=@0x40018014) at
../boost138inst/include/boost-1_38/boost/interprocess/sync/emulation/interprocess_cond
ition.hpp:70
-----Original Message----- From: ZHOU,JON (A-China,ex2) Sent: Tuesday, September 08, 2009 10:21 AM To: boost@lists.boost.org; ZHOU,JON (A-China,ex2) Subject: [interprocess]why message_queue receive() will consume so much CPU resource
Hi there
I just found that message_queue::receive() or message_queue:: timed_receive () consume high CPU resource, (99% CPU) the code like the below:
//create message_queue
date d(2009,Sep,8); //an arbitrary date //construct a time by adding up some durations durations ptime t1(d, hours(0)+minutes(0)+seconds(1)+millisec(0));
while (1) { for(int i = 0; i < 100; ++i){ int number; //mq.receive(&number, sizeof(number), recvd_size, priority); mq.timed_receive(&number, sizeof(number), recvd_size, priority,t1); } }
As I know, both the receive() & timed_receive() are block method, there should be sleep mechanism inside. why it still need so much CPU resource?
Thanks jon
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi there: Can message_queue implement a variable message size? Or how does it handle if the message size exceed? truncate? Regards jon
jon_zhou@agilent.com escribió:
Hi there:
Can message_queue implement a variable message size? Or how does it handle if the message size exceed? truncate?
ThrowS interprocess_exception(size_error). See the documentation. http://www.boost.org/doc/libs/1_40_0/doc/html/boost/interprocess/message_que... Best, Ion
On Mon, Sep 7, 2009 at 5:12 PM, Adam Badura<abadura@o2.pl> wrote:
I experienced compilation problems with Boost 1.40. I am using Visual Studio 2005 and 2008. On both Boost compiles and links fine but is unusable in other code due to compilation errors. Currently I have access to errors produced on 2008 and it would be troublesome to get errors for 2005 (but if needed I will do it) - however the are the same (as to the message):
1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template
and so on... It is hard for me to tell which header causes the error but if requested I will look for this.
It migh help if you could identify which Boost library is causing the problem, and then post an error report with specifics, beginning the subject line with the library name in square brackets. Take a lot at other similar postings. Thanks, --Beman
participants (7)
-
Adam Badura -
Beman Dawes -
Christian Schladetsch -
Ion Gaztañaga -
jon_zhou＠agilent.com -
Rodrigo Pinho Pereira de Souza -
vicente.botet