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

[Gustavo Carneiro]

2008/7/30 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

>
> On Wed, 2008-07-30 at 12:25 +0100, Gustavo Carneiro wrote:
> >
> >
> > 2008/7/30 <craigdo at ee.washington.edu>
>
> >
> > 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.
>
> Presumably, you could even push the calls to Lock and Unlock down into
> RunOne.
>
> >
> > Back to my GUI problem, the naive approach that I had in mind was:
> >
> > Mutext g_myMutex;
> >
> > void MySimulatorRun ()
> > {
> >     while (!Simulator::IsFinished ())
> >    {
> >       g_myMutex.Lock ();
> >       Simulator::RunOne ();
> >       g_myMutex.Unlock ();
> >    }
> > }
> >
> > // called every 100ms or so
> > void GuiUpdateTimeout ()
> > {
> >       g_myMutex.Lock ();
> >       // collect data, update display
> >       g_myMutex.Unlock ();
> > }
> >
> > Now, the above approach is kind of naive because it does a lock/unlock
> > pair for _every event_, which is bound to have some performance
> > implication.   A more clever approach is to unlock-then-lock only once
> > out of N events.  N should be selected such that lock/unlock is done
> > only about once every ~ 10ms.  The hard part is to figure out what is
> > the correct N for that.  I think it depends on the simulation, and N
> > cannot even be constant, so it has to be discovered adaptively, by
> > measuring elapsed time for any previous N iterations and adjusting N
> > accordingly.
>
> I think that a much simpler approach would be to use a lockless system
> with a one-writer/one-reader queue of commands sent from the GUI to the
> simulation thread.


Been there, done that (see gjc/ns-3-viz).  At the end of the day, it's just
a PITA to serialize data back and forth through a pipe.  It's far easier to
just grab whatever data I am interesting in directly from the nodes.

Besides, what data structure allows me to read/write data _without locks_?
I must be missing something fro libstdc++ :)


>
>
> i.e.,
>
> class SimulationCommand
> {
> public:
>  virtual void Execute (void) = 0;
> };
>
> class SimulationCommandQueue
> {
> public:
>  // push at the back of the queue. will be unqueued last
>  void PushBack (SimulationCommand *command);
>  // push at the front of the queue. will be unqueued first
>  void PushFront (SimulationCommand *command);
>  // return 0 if no commands
>  SimulationCommand *PopFront (void);
> };
>
> class PauseSimulationCommand
> {
> public:
>  virtual void Execute (void) {Simulator::Stop ();}
> };
>
> SimulationCommand *cmd = new PauseSimulationCommand ();
> // this is a high priority command, so push at front.
> queue->PushFront (cmd);
>
>
> Mathieu
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert