[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)