Question

I want to implement a scheduler class, which any object can use to schedule timeouts and cancel then if necessary. When a timeout expires, this information will be sent to the timeout setter/owner at that time asynchronously.

So, for this purpose, I have 2 fundamental classes WindowsTimeout and WindowsScheduler.

class WindowsTimeout
{
  bool mCancelled;
  int mTimerID; // Windows handle to identify the actual timer set.
  ITimeoutReceiver* mSetter;

  int cancel()
  {
    mCancelled = true;

    if ( timeKillEvent(mTimerID) == SUCCESS) //  Line under question # 1
    {
        delete this; // Timeout instance is self-destroyed.
        return 0; // ok. OS Timer resource given back.
    }
    return 1; // fail. OS Timer resource not given back.
  }

  WindowsTimeout(ITimeoutReceiver* setter, int timerID)
  {
     mSetter = setter;
     mTimerID = timerID;
  }

};

class WindowsScheduler
{
    static void CALLBACK timerFunction(UINT uID,UINT uMsg,DWORD dwUser,DWORD dw1,DWORD dw2)    
{
     WindowsTimeout* timeout = (WindowsTimeout*) uMsg;
     if (timeout->mCancelled) 
          delete timeout;
     else
          timeout->mDestination->GEN(evTimeout(timeout));
}
WindowsTimeout* schedule(ITimeoutReceiver* setter, TimeUnit t)
    {
        int timerID = timeSetEvent(...);
        if (timerID == SUCCESS)
        {
             return WindowsTimeout(setter, timerID);
        }
        return 0;
    }
};

My questions are:

Q.1. When a WindowsScheduler::timerFunction() call is made, this call is performed in which context ? It is simply a callback function and I think, it is performed by the OS context, right ? If it is so, does this calling pre-empt any other tasks already running ? I mean do callbacks have higher priority than any other user-task ?

Q.2. When a timeout setter wants to cancel its timeout, it calls WindowsTimeout::cancel().
However, there is always a possibility that timerFunction static call to be callbacked by OS, pre-empting the cancel operation, for example, just after mCancelled = true statement. In such a case, the timeout instance will be deleted by the callback function.
When the pre-empted cancel() function comes again, after the callback function completes execution, will try to access an attribute of the deleted instance (mTimerID), as you can see on the line : “Line under question # 1” in the code.

How can I avoid such a case ?

Please note that, this question is an improved version of the previos one of my own here:
Windows multimedia timer with callback argument

Answer 1

Q1 – I believe it gets called within a thread allocated by the timer API. I’m not sure, but I wouldn’t be surprised if the thread ran at a very high priority. (In Windows, that doesn’t necessarily mean it will completely preempt other threads, it just means it will get more cycles than other threads).

Q2 – I started to sketch out a solution for this, but then realized it was a bit harder than I thought. Personally, I would maintain a hash table that maps timerIDs to your WindowsTimeout object instances. The hash table could be a simple std::map instance that’s guarded by a critical section. When the timer callback occurs, it enters the critical section and tries to obtain the WindowsTimer instance pointer, and then flags the WindowsTimer instance as having been executed, exits the critical section, and then actually executes the callback. In the event that the hash table doesn’t contain the WindowsTimer instance, it means the caller has already removed it. Be very careful here.

One subtle bug in your own code above:

WindowsTimeout* schedule(ITimeoutReceiver* setter, TimeUnit t)
    {
        int timerID = timeSetEvent(...);
        if (timerID == SUCCESS)
        {
             return WindowsTimeout(setter, timerID);
        }
        return 0;
    }
};

In your schedule method, it’s entirely possible that the callback scheduled by timeSetEvent will return BEFORE you can create an instance of WindowsTimeout.