[Ns-developers] timers, events, et al: summary
riley at ece.gatech.edu
Thu Aug 9 09:53:29 PDT 2007
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.
Dr. George F. Riley, Assistant Professor
The School of Electrical and Computer Engineering at Georgia Tech
Atlanta, GA 30332-0250
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
>> patterns of timers in ns-2 models and in the ns-3 models we have
>> (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
>> - 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
>> - typically, reschedule, only once the event has expired. i.e., it
>> 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
>> in his Timer class, minus the automatic Cancel in Schedule (which
>> be replaced by an ASSERT (IsExpired ())) and minus the automatic
>> in the destructor. This leaves us with a class which is responsible
>> - 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
>> 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 ?
> I understand your arguments for not providing a second API for doing
> 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
> 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
> 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.
More information about the Ns-developers