[Ns-developers] merging multithreaded simulation core incrementally

[Mathieu Lacage]

hi,

Guillaume announced recently his effort to implement a multithreaded
simulation core to run simulations on multicore systems:
http://mailman.isi.edu/pipermail/ns-developers/2009-July/006197.html

Given the current status of the project, I don't think the simulator
implementation will be mergeable before next release (we still need
serious time to try various algorithms, profile, and make the
implementation really robust) but there are some things which do make
sense as standalone changes to ns-3 and which could be merged
separately: the idea would be to prepare at least a single patch for
each of the items below.

1) keep track of a 'context' (a 32bit node id) on a per-event basis. The
user-visible feature here is that there is a new function: uint32_t
Simulator::GetContext (void); and this function is used by the logging
code in src/core/log.h/cc to print automatically with each log line the
'current' context of a running event. This feature is not completely
deterministic: that is, in some cases, it is possible that the current
context is '-1' (when it happens, it's easy for users to slightly change
their model code to make it not happen. By default, it should not happen
with the default set of models in ns-3) which means, no context/nodeid
is associated to an event. This is why this is really a debugging
feature but a really useful one.

2) introduce an AsciiWriter which mirrors PcapWriter. It encapsulates
the details of our ascii output file format. In the multithreaded code,
it is used to ensure that each line in an ascii file is written
atomically but we could merge a simple version of that code which merely
centralizes knowledge of the ascii file format.

3) make simulator.h threadsafe: this requires the addition of assembly
atomic operations (stolen from glib) to implement RefCountBaseThreadSafe
and use it from EventImpl, as well as the use of a mutex lock in
DefaultSimulatorImpl, similarly to RealtimeSimulatorImpl. A nice
side-effect of this new feature is that it would allow getting rid of
some ugly code in the emu and tab-bridge devices. The performance cost
of that change is around 10% in micro-benchmarks for Scheduling
operations, most of which is coming from the lock mutex in
DefaultSimulatorImpl. I have not measured any impact on non-micro
benchmarks.

4) various changes to the simulator.h API to make it nicer to the
non-default SimulatorImpl subclasses:
  - make Simulator::SetScheduler take an ObjectFactory rather than a
Ptr<Scheduler>
  - kill Simulator::RunOneEvent, IsFinished, and, Next
  - introduce Simulator::SetMonitoringCallback(Callback<void> cb);

5) changes to various APIs in src/core to make them threadsafe or make
it easier to do threadsafe things. I have not yet investigated the cpu
runtime cost of these features (they have no memory cost). This is
really about:
  - use RefCountBase where users use their own refcounting
implementation.
  - replace RefCountBase by RefCountBaseTs where needed
  - make Object::Ref/Unref threadsafe.
  - make AsciiWriter threadsafe
  - remove Packet::PeekData and use Packet::CopyData instead where
needed. This will make it easier to use a non-COW implementation of
Packet if needed in the multithreaded case.

Although I am maintainer for most of the code touched by these proposed
changes (everything except the ascii writer), I would like feedback on
these proposed API changes/additions. I will work to prepare a separate
patch for each item above over the next couple of days. If you have
questions and/or comments, it would be really helpful to voice them now.

Mathieu