« Previous | Next » 

Revision 0e7ff5c8

ID0e7ff5c845cc8caa56f4ed6f37b2918b84466d7e

Added by Simon Tenbusch about 8 years ago

[nullduration] moved asyncModuleLocks to earlier position and added getProcessingDelay return value that makes the event get handled sequentially:
We have to lock before getProcessingDelay is called, and must only be released, once the corresponding event has been handled. This is because in the meantime, other events could alter the module and therefore change the outcome of getProcessingDelay nondeterministically.

Also in the sequential case, we still have to lock because it could be the case that a parallel event on the same module is active while we try to execute a sequential one.

The locking is now taking place in cMessage::getEventDuration, which calls getProcessingDelay. Unlocking takes now place both after sequential and parallel execution.

If SimTime::simTimeSequentialExecution is returned by getProcessingDelay, the event is handled sequentially with duration 0 (useful for management events)

Files

  • added
  • modified
  • copied
  • renamed
  • deleted

View differences