Bug 1417 - DefaultSimulatorImpl no longer allows scheduling from multiple threads
DefaultSimulatorImpl no longer allows scheduling from multiple threads
Status: RESOLVED DUPLICATE of bug 1410
Product: ns-3
Classification: Unclassified
Component: core
ns-3-dev
All All
: P5 major
Assigned To: Mathieu Lacage
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-23 11:11 EDT by Gustavo J. A. M. Carneiro
Modified: 2012-04-24 08:41 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gustavo J. A. M. Carneiro 2012-04-23 11:11:16 EDT
The DefaultSimulatorImpl no longer allows scheduling from multiple threads. It seems to note which is the "main" thread and asserts that only this thread can schedule events.


DefaultSimulatorImpl::Schedule (Time const &time, EventImpl *event)
{
  NS_ASSERT_MSG (SystemThread::Equals (m_main), "Simulator::Schedule Thread-unsafe invocation!");


This breaks the visualizer in some cases (namely when you run it from a python simulation script).  The visualizer can call Simulator::Schedule from multiple (2) threads, but it use a mutex to make sure only one thread at a time can call the ns-3 API.  This assert is excessive.

cf. bug 631 comments.
Comment 1 Tom Henderson 2012-04-23 17:11:12 EDT
this seems to be a duplicate of bug 1410.
Comment 2 Gustavo J. A. M. Carneiro 2012-04-24 05:50:43 EDT

*** This bug has been marked as a duplicate of bug 1410 ***
Comment 3 Mathieu Lacage 2012-04-24 08:19:41 EDT
Just a FYI, this is assert is not going away unless you find a safe way to know for sure that ::Run is _really_ not running in another thread so, it would be a good idea to find a better way to do what you want to do in the visualizer.
Comment 4 Gustavo J. A. M. Carneiro 2012-04-24 08:41:50 EDT
(In reply to comment #3)
> Just a FYI, this is assert is not going away unless you find a safe way to know
> for sure that ::Run is _really_ not running in another thread so, it would be a
> good idea to find a better way to do what you want to do in the visualizer.

How about Simulator::Lock() and Simulator::Unlock(), for safe multithreading? It would be trivial to switch pyviz to use that.