NO-JIRA: Fix for potential Timer deadlock issue:

- Previously we used a mutex to prevent cancelling a TimerTask whilst it
  was still executing from within its callback in another thread.

  This violates the principle that you shouldn't hold locks when calling
  the arbitrary code in a callback, and so is subject to potential
  deadlock problems.

- This fix only works if no timer callback calls TimerTask::cancel();
  this is true with the current code. And there is no good reason to
  call cancel() from within a callback, as cancel is the default
  behviour in any case - you have to specifically reschedule a
  recurring timer.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1357827 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 5 insertions, 2 deletions

diff --git a/cpp/src/qpid/sys/Timer.h b/cpp/src/qpid/sys/Timer.h
index fccb17dbc2..af0b1b6803 100644
--- a/cpp/src/qpid/sys/Timer.h
+++ b/cpp/src/qpid/sys/Timer.h
@@ -40,6 +40,7 @@ class Timer;
 
 class TimerTask : public RefCounted {
   friend class Timer;
+  friend class TimerTaskCallbackScope;
   friend bool operator<(const boost::intrusive_ptr<TimerTask>&,
                         const boost::intrusive_ptr<TimerTask>&);
 
@@ -47,9 +48,11 @@ class TimerTask : public RefCounted {
     AbsTime sortTime;
     Duration period;
     AbsTime nextFireTime;
-    Mutex callbackLock;
-    volatile bool cancelled;
+    qpid::sys::Monitor stateMonitor;
+    enum {WAITING, CALLBACK, CANCELLED} state;
 
+    bool prepareToFire();
+    void finishFiring();
     bool readyToFire() const;
     void fireTask();