[ace-users] ACE_TP_Reactor cancel_timer and handle_timeout

Johnny Willemsen jwillemsen at remedy.nl
Sun May 24 13:03:48 CDT 2015


Hi,

> 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.

No, in a single threaded case there is only one thread.

> 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()?

That is also what I would expect. At the moment the timer isn't canceled
and the response of your original CORBA call hasn't received and the
timer triggers again the code will make another CORBA call, the thread
isn't blocked when you make an outgoing CORBA call (in the default case
which I would recommend *not* to change)

Regards,

Johnny

> 
>  
> 
> 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,
> 
>  
> 
> 
> 
> _______________________________________________
> ace-users mailing list
> ace-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-users
> 



More information about the ace-users mailing list