Revision 0e7ff5c8


Added by Simon Tenbusch almost 9 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)

View differences:

125 125
126 126
        cAsyncModule* aMod = (cAsyncModule*) mod;
127 127
        simtime_t duration = msg->getEventDuration();
        if (aMod->mayParallelize(msg, duration) && sim->threadPool)
        if (duration != SimTime::simTimeSequentialExecution && aMod->mayParallelize(msg, duration) && sim->threadPool)
129 129
130 130
131 131
            // create a new barrier and schedule it

Also available in: Unified diff