[ace-users] ACE_TP_Reactor cancel_timer and handle_timeout

[Steve Huston]

In multi-thread scenarios, all shared state needs to be protected against access/change by multiple threads. Protecting the state by a mutex is often the mechanism used for this. The ACE_Guard classes are useful for ensuring that locks are not accidentally left held.

C++NPv1 chapter 10 and APG chapter 12 have more details about how to correctly use locks and guards in ACE.
http://www.riverace.com/acebooks/index.htm

-Steve

From: ace-users [mailto:ace-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Nicole Neo
Sent: Thursday, May 21, 2015 7:00 AM
To: ace-users at list.isis.vanderbilt.edu; joris.guisson at esaturnus.com
Subject: Re: [ace-users] ACE_TP_Reactor cancel_timer and handle_timeout

In my project, we maintain a variable to keep track of whether the timer is actually running before attempting to cancel that timer. If cancel timer fails after that check, we assume it's already been in the event queue to be processed next.

On Thursday, May 21, 2015 at 8:55:47 AM UTC+1, joris.... at esaturnus.com<mailto:joris.... at esaturnus.com> wrote:
Situation:

ACE 6.0.3 running on 32 bits debian wheezy.

We are using an ACE_TP_Reactor with one thread, we notice that it is possible for a timer to still be called after cancel_timer has been called.

This is the sequence of events leading up to it:

- A notify event causes the reactor to call one of our event handlers
- The event handler cancels a timer, and invalidates an object which will be used in the handle_timeout code of the timer.
- The event handler does a synchronous outbound CORBA call.
- During the handling of the CORBA call, the reactor runs again, and calls handle_timeout for the timer we just canceled.
- In the handle_timeout, we attempt to access the object which got invalidated just after the cancel_timer. And then we crash.

We can fix this crash easily in our code, but the question here is, is this valid behavior of the ACE_TP_Reactor ?

What happens when a timer has expired and is ready to be executed, but another event handler is called first, and cancels this timer ?

Joris,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/cgi-bin/mailman/private/ace-users/attachments/20150521/062667dd/attachment.html>