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