[Ns-developers] NS-3 GUI (visualization again)

craigdo at ee.washington.edu craigdo at ee.washington.edu
Wed Jul 30 10:49:46 PDT 2008


> > void MySimulatorRun ()
> > {
> >     while (!Simulator::IsFinished ())
> >    {
> >       Simulator::Lock ();
> >       Simulator::RunOne ();
> >       Simulator::UnLock ();
> >    }
> > }
> > 
> > I would expect the above to work and make sense even for 
> the threaded
> > simulator.  It's all about documentation.  No need to assert in
> > Simulator::RunOne, just put in the documentation that you must hold
> > the simulator lock before calling it.

There's more to the story than this.

What I wrote earlier was that I would have an assert there for a realtime
simulator.  I think this is correct.

How does the code above have any relation whatsoever to real time?  You
can't just call RunOne at random times.  You have to run the event at the
head of the queue at the real time at which it expects to be run.  This is
the realtime piece of the puzzle that you will have to solve in your GUI.
There are other interesting (more difficult) things you have got to do if
you want to be able to have other threads scheduling events while your run
thread is (sleep) waiting for the current event deadline to expire.  This is
the interruptible-wait piece of the puzzle.  This is what I meant when I
said that if you want to implement your own realtime scheduler loop you,
"move basically the whole multithreaded interruptible-wait
realtime-synchronizer thing up into the GUI application."  This still sounds
like a bad plan to me although nothing is stopping you (use the default
simulator implementation and make your own realtime scheduling of RunOne in
your GUI).

There is another level of simulation you can use, however, which seems to be
the case you are assuming.  This is *not* a realtime simulator, this is
using the multithreaded simulator in a free-time simulation.  By default the
emu code comes as a realtime simulator, however, you can decide that you
don't want to sync to realtime and set what I called a null synchronizer.
Then your GUI loop could start to look like yours above.  This would buy the
ability to support Simulator::ScheduleNow or Simulator::Schedule calls from
other threads (real devices) in a non-realtime environment; but I'm not sure
how meaningful of a scenario that would be.

In any case, if you thought it was a reasonable case to support, RunOne
could check to see if there is realtime going on under the sheets and look
more like,

  bool
  DefaultSimulatorImpl::RunOne (void)
  {
    if (m_synchronizer->Realtime () == false)
      {    
        if (!m_events->IsEmpty ())
          {
            ProcessOneEvent ();
          }
          ...
      }
     else
      {
        NS_ASSERT_MSG(false, "No, you really don't want to do that");
        return false;
      } 
  }

The bottom line is that I think running an event without consideration of
the event execution time in a realtime simulation is a nonsense request and
the system should respond with an assert.  If you want to admit the
possibility of degenerate cases, okay, we could refine the assert to admit
another case.  If you are a brave user and know exactly what you are doing,
you can provide a simulator implementation that does anything your heart
desires including building some kind of realtime GUI.

-- Craig





More information about the Ns-developers mailing list