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

Mathieu Lacage mathieu.lacage at sophia.inria.fr
Wed Jul 30 09:19:22 PDT 2008


On Wed, 2008-07-30 at 17:06 +0100, Gustavo Carneiro wrote:
> 
> 
> 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.

You don't need to do that for all data. You can do it just to stop and
restart the simulation thread. Once that is done, there is no need to go
through the command queue and you can call the simulation APIs directly
from the GUI.

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

There is nothing in libstdc++ but you can implement your own or, better,
rip out one from the internet. 

http://www.ddj.com/hpc-high-performance-computing/208801974
http://groups.google.com/group/comp.programming.threads/browse_thread/thread/effb92d0bfb53962

But, really, you don't need this fancy stuff. You could use a lock to
protect the queue and just check the queue counter outside of the lock:
the result won't be totally right (one or more extra events could be
scheduled) but it will be fast which, in this case, is what matters.

Mathieu




More information about the Ns-developers mailing list