[Ns-bugs] [Bug 631] RealtimeSimulatorImpl not compatible with python bindings

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=631





--- Comment #13 from Craig Dowell <craigdo at ee.washington.edu>  2009-07-13 17:02:28 EDT ---
> Writing a GUI is not what I could call a "simple case".

Not that it's super-important, but I'm not suggesting that writing a GUI is
simple.  I'm suggesting that we should continue to support a simple way to
single step the simulation, which in turn, makes this kind of application
easier to write.  We have a user suggesting that this makes his life easier,
and I can see his point clearly.

[ ... ]

>>   DynamicCast<RealtimeSimulatorImpl> (
>>     Simulator::GetImplementation ())->ScheduleRealtimeNow (
>>       MakeEvent (&EmuNetDevice::ForwardUp, this, buf, len));
>
> Simulator::Schedule* needs to be thread-safe to get rid of this,
> I think, right?. 

Yes.  These methods are thread-safe in the realtime simulator, but not in the
default case.  However, IMO, having ScheduleReal method along side of Schedule
methods is dangerous since there are side-effects that may bite users (cf,
non-discrete-event simulator anymore makes certain models stop working).

>i.e., we need to profile whether the cost of taking a lock 
> in each method of DefaultSimulatorImpl and making 
> EventImpl::Ref/Unref threadsafe is not a performance problem
> (I have local patches for the latter). If not, then, we
> should kill this ugly code (which I am responsible for, I know).

Having thread safe methods seems like a good idea, but it probably means a
kernel call in the MP case.  We might be able to get away with a TAS
instruction optimization, but this is pretty much the definition of
non-portable :-)

I still think the realtime versions should be broken out so that non-real-time
simulations can't be lulled into thinking they are or doing something possibly
completely unexpected.  It makes sense to me to break out the single step
stuff.

[ ... ]

> A callback seems really very reasonable, unless, of course, someone 
> can point out a fundamental flaw with that idea.

I always thought that these callbacks could be scheduled just like any other
event, BTW.  With the realtime scheduler, you could just arrange to have
yourself called back every 100ms, for example.

If you write an event loop with a message pump, your callback can just send a
message to the event loop, but this implies a thread for running the message
pump and a thread for calling into the simulator.  So you begin talking
multithreaded pretty quickly.

If you just have a single step method, you can call it out of your event loop
and don't have to deal with multithreading.

It's just easier to deal with, IMO.

> > > But if you think about it, this is quite similar to a QI but lacks the
> > clean-ness of the interface separation.

> I have a very hard time understanding how this is any different 
> from using Simulator::GetImplementation ()->GetObject<MyCapability> () 
> which I could live with but which, really, I would like to avoid.

Like I said, it's "quite similar."  The difference is that you can share one
interface class across simulator implelemtations and then don't have a
dependency on the concrete class of the implementation in the client.  More
than one concrete implementation class can provide a single SingleStep
interface and the client doesn't have to know every possible concrete class to
work with multiple of them.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.