Re: Lahman, how ya doing?

In article <epeq61tbch76mo7dlkgqlj36vqrt9rfov2@xxxxxxx>,
Robert C. Martin <u.n.c.l.e.b.o.b@xxxxxxxxxxxxxxxx> wrote:
>On Sun, 24 Apr 2005 19:48:53 +0000 (UTC),
>glhansen@xxxxxxxxxxxxxxxxxxxxx (Gregory L. Hansen) wrote:
>
>>#include "control.h"
>>int main()
>>{
>> ControlBlock c1(1), c2(2), c3(3);
>>
>> Timer t1(3); // trigger every 3 seconds
>> t1.add_task(&c1);
>> t1.add_task(&c2);
>>
>> DoubleTimer t2(5,7); // event1 every 5 s, event2 every 7
>> t2.add_task(&c3);
>>
>> Clock clock; // default 1 tick per second
>> clock.add_timer(&t1);
>> clock.add_timer(&t2);
>>
>> for (int i = 0; i < 10; i++)
>> clock.tick();
>>
>> return 0;
>>}
>
>
>I would do this a bit differently. I'd build the Timer class so that
>you could do this:
>
>Timer timer;
>timer.addTask(c1, 3); // do C1 every three seconds.
>timer.addTask(c2, 3); // do C2 every three seconds.
>timer.addTask(c3, 5); // do C3 every five seconds.
>timer.addTask(c4, 7); // do C7 every seven seconds.

Just when I think I have the basic infrastructure ready to go, with the
rest of the problem reduced to one particular block or another, I get a
sensible suggestion.

I've already realized a weakness in that last loop, and changed it so that
it can be replaced with

clock.run(10); // run for 10 seconds

That loop is the kind of grunt work that shouldn't appear in the
interface. And the length of a tick may be an input parameter,
determining the time resolution, but ticks shouldn't be part of normal
interfacing.


--
"When the fool walks through the street, in his lack of understanding he
calls everything foolish." -- Ecclesiastes 10:3, New American Bible
.

Relevant Pages

  • Re: I made a patch and would like feedback/testers (drivers/cdrom/aztcd.c)
    ... >>Otherwise the loop could time out after only a few nanoseconds.. ... > least one timer tick which is longer than 2ms at low HZ values. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Lahman, how ya doing?
    ... That allowed one to define the scheduling in the way Timer::add_task() was invoked rather than embedding the scheduling rules in the implementation of Timer. ... They should not be concerned with sequencing their activities within the overall solution context. ... More important, given your explanation below, is that ChartRecorder should not know about the rules and policies that determine the correct sequencing in the overall flow of control. ... Just have it enforce the simple rules that multiple events on the same tick are issued in the order that they were defined. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... Object* recipient; int event_id; ... Timer ... Not relevant to my simulation, but generalizing to a case where any amount of time can pass between when an event is pushed on to the queue and when it is popped off and processed, it seems you can have two identical events going to the same object. ... given tick. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... That allowed one to define the scheduling in the way Timer::add_task() was invoked rather than embedding the scheduling rules in the implementation of Timer. ... In your problem Timer has to churn out events on a schedule that is based on counting time units (clock ticks or simulation ticks). ... Just have it enforce the simple rules that multiple events on the same tick are issued in the order that they were defined. ... By employing true event-based processing you completely separate the concerns of determining when the Beam should do its thing from the concerns of what it needs to do. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... >>>so far can be accommodated by the way the events are registered with Timer. ... >>>in the real controller). ... >>>tick is done. ... >>>sequencing of Chart's responsibilities, especially relative to other ...
    (comp.object)