Boost logo

Boost :

Subject: Re: [boost] [interprocess]why message_queue receive() will consume so much CPU resource
From: Rodrigo Pinho Pereira de Souza (pinhopro_at_[hidden])
Date: 2009-09-11 22:04:36


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_at_[hidden]> wrote:

> I think this is best dealt with by the OS.
>
> On Wed, Sep 9, 2009 at 9:40 PM, <jon_zhou_at_[hidden]> 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_at_[hidden]'
> > 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_at_[hidden]; 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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk