[Ns-developers] timers, events, et al: summary

[George Riley]

I agree with Tom that we should have a Timer class.
It just makes good sense and most who are familiar with discrete
event simulations will expect such a feature.  Yes, we can do the
same think with directly scheduling events, but I prefer providing
things that make users more comfortable.

George
------------------------------------------------------------------------ 
--------------------
Dr. George F. Riley, Assistant Professor
The School of Electrical and Computer Engineering at Georgia Tech
Atlanta, GA  30332-0250
(404)-894-4767
E-Mail: riley at ece.gatech.edu

ECE3090 Web Page: http://users.ece.gatech.edu/~riley/ece3090/
ECE2040 Web Page: http://users.ece.gatech.edu/~riley/ece2040/
On Aug 6, 2007, at 2:43 AM, Tom Henderson wrote:

> Mathieu Lacage wrote:
>> To make progress on this issue, I spent a good while reviewing the  
>> usage
>> patterns of timers in ns-2 models and in the ns-3 models we have  
>> already
>> (802.11, olsr, application, csma-cd, p2p). The outcome is that, it is  
>> hard to pinpoint common use-cases but, if I
>> had to pick a really common operation, it would be the following:
>>   - schedule multiple times a single function
>>   - often, schedule the function with the same delay over and over  
>> again
>>   - often also, use a different delay every time
>>   - most of the time, zero arguments to the function
>>   - when there are arguments, their values are changed for each  
>> schedule
>>   - typically, reschedule, only once the event has expired. i.e., it  
>> is
>> safe to assert on the event expiration before calling schedule (ns-2's
>> sched. It is interested to note that a lot of calls to resched in ns-2
>> could likely be changed to calls to sched instead).
>> So, what do we have here ? We have the features which gustavo  
>> suggested
>> in his Timer class, minus the automatic Cancel in Schedule (which  
>> should
>> be replaced by an ASSERT (IsExpired ())) and minus the automatic  
>> Cancel
>> in the destructor. This leaves us with a class which is responsible  
>> for:
>>   - holding a function pointer and a default delay
>>   - asserting on schedule that  the event is not still running
>> The pros for adding such a class would be that we are going to save
>> users from writing a bit of code:
>> ASSERT (m_ev.IsExpired ());
>> m_ev = Simulator::Schedule (delay, &MyClass::FooMethod, this);
>> is going to become, in a few cases when the user's use of this event
>> matches that of our timer:
>> m_timer (delay, &MyClass::FooMethod, this);
>> m_timer.Schedule ();
>> So, indeed, we are going to save our users a few keystrokes in a few
>> cases but the real amount of text we are going to save is quite  
>> limited.
>> The cons are that the cases where users will be able to use this class
>> are common but they are not a majority so, for everything else, users
>> will have to use the low-level API: they will have to learn the two
>> APIs, and we will have to read code which uses both. So, we have twice
>> the amount of work during the learning phase of the API.
>>> From my perspective, the cons outweigh the pros so, I would tend to
>> stick to my earlier proposals to not include a Timer class.
>> Are there more comments, counter-proposals, or counter-analysis of
>> use-cases ?
>> Mathieu
>
> I understand your arguments for not providing a second API for doing  
> the
> same thing, even if it is a syntactic shortcut.  In this case, I have
> leaned towards supporting the timer class because it seems to be the
> most prevalent use of the calls to schedule events, and conceptually it
> seems to me that a discrete event network simulator ought to have a
> timer class.
>
> My own rough survey of the ns-2 code suggested to me that calls to  
> timer
> scheduling operations were about the same frequency in the code as all
> other protocol model calls to the scheduler (excluding
> Scheduler::instance().clock calls), so I would estimate that roughly
> half of the scheduling calls in the ns-2 source seem to be
> timer-related.  Some protocol models in ns-2 make exclusive use of
> timers and had no calls to the raw scheduler API, while others use a  
> mix
> of timers and scheduler calls, and others do not use timers.
>
> I would be curious to hear other opinions if people feel strongly one
> way or another.
>
> Tom
>