[ace-users] ACE_TP_Reactor cancel_timer and handle_timeout

[Steve Huston]

Ah, my apologies – I assumed from use of ACE_TP_Reactor that you had multiple threads.

I believe, but am not sure, that the nested CORBA invocation is using another thread but I don’t know if that is germane to the problem here.

If the timer was actually canceled, you should not have gotten a handle_timeout callback for that timer in that same thread. So it seems that something may be wrong. Did you check the return value from cancel_timer()?

TAO guys – does this make sense?

-Steve

From: Joris Guisson [mailto:joris.guisson at esaturnus.com]
Sent: Friday, May 22, 2015 1:55 AM
To: Steve Huston
Cc: Nicole Neo; ace-users at list.isis.vanderbilt.edu
Subject: Re: [ace-users] ACE_TP_Reactor cancel_timer and handle_timeout

What has that got to do with this problem ? We are only using one thread for the reactor, there is no multi threading involved here.

Joris,



2015-05-21 22:12 GMT+02:00 Steve Huston <shuston at riverace.com<mailto:shuston at riverace.com>>:
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<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<mailto:ace-users at list.isis.vanderbilt.edu>; joris.guisson at esaturnus.com<mailto: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/20150522/f3a5bb12/attachment.html>