Re: [Boost-users] ASIO, boost::function in VC7.1

Subject: Re: [Boost-users] ASIO, boost::function in VC7.1
From: Kimon Simons (kimon.simons_at_[hidden])
Date: 2009-04-25 17:22:27

Thank you very much Igor.

I acknowledge my ignorence regarding the thread safety issues involved, so I
would like dig a little bit deeper here, if you do not mind. If there is a
point in the docs that I should be looking and that I have not my apologies.
I would appreciate it if you could point me there.

Most of the examples that I have come across for timers have as a
precondition that the io_service::run function has been invoked yet;
reseting the timer happens withing the timer handler in general.
I am wondering what are  the issues involved when calling
deadline_timer::async_wait, deadline_timer::cancel for a timer that is
associated with an io_service object when io_service::run has already
started in a different thread? Or in other words following the point "* the
io_service may be being run in a background thread that is launched prior to
the application's asynchronous operations*"  in
http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/reference/io_service.html,
how do I launch asynch operations using an io_service that has already being
run?

This is relevant to what I really want to do which is:

1.Start io_service::run in one background thread
2.Start async timers on demand from the main thread that should be executed
on the io_service::run thread. These timers will be associated with an event
that will trigger a thread safe handler on a registerd observer(in this case
the Counter class).
3. Modify/cancel from the main thread timers that have outstanding async
operations in the io_service::run thread.

In the particular example below, the member function onIncrement of the
class Counter is not thread safe, but since the io_service::run is running
on a one thread, only one handler will be invoked on the thread that runs
io_service::run, so implicitly there is a serialization of access, correct?

My question is what is the best practice, in order to achieve 2 and 3 above?
Suprisingly, after building my toy case with your help, the effect is what I
expected, but I admit that your comment made me realize that I still need to
dig further in order to understand all the issues involved.

I would be grateful for any comment or suggestion.

Thanks a lot.

Kimon

On Sat, Apr 25, 2009 at 8:38 PM, Igor R <boost.lists_at_[hidden]> wrote:

> >         m_timer.async_wait(boost::bind(&IntervalEvent::handler, this));
>
> should be: m_timer.async_wait(boost::bind(&IntervalEvent::handler, this,
> _1));
> or:
> m_timer.async_wait(boost::bind(&IntervalEvent::handler, this,
> boost::asio::placeholders::error));
>
>
> >     void handler(boost::system::error_code& error)
> should be: void handler(cosnt boost::system::error_code& error)
>
>
> > Further to that, I am wondering, in principle should I cancel the
> deadline_timer on the destructor of the IntervalEvent class? Does the
> io_service class know when any of the deadline_timers that is being
> registered goes out of scope?
>
> On destruction, the timer cancels itself anyway.
>
> By the way, you access the timers both from main() and from another
> thread - which is illegal, since the asio objects are not thread-safe
> (except for io_service).
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users