Project

General

Profile

Revision 0e7ff5c8

ID0e7ff5c845cc8caa56f4ed6f37b2918b84466d7e

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:

src/sim/cmessage.cc
84 84
    heapindex = -1;
85 85
    prev_event_num = -1;
86 86

  
87
    duration = -1;
87
    duration = SimTime::simTimeUninitialized;
88 88
    msgtreeid = msgid = AO_fetch_and_add1(&next_id);
89 89
    AO_fetch_and_add1(&total_msgs);
90 90
    AO_fetch_and_add1(&live_msgs);
......
373 373
}
374 374

  
375 375
simtime_t cMessage::getEventDuration() {
376
    if (duration < 0) {
376
    if (duration == SimTime::simTimeUninitialized) {
377 377
        cSimpleModule* mod = (cSimpleModule*) simulation.getModule(getArrivalModuleId());
378 378
        if (mod && mod->isAsyncModule()) {
379
            // block if another thread is busy inside this module
380
            // then set the module to busy
381
            // this must only be unset after the corresponding event has been processed,
382
            // since otherwise the return value of getProcessingDelay is not deterministically determined
383
            // (in the mean time there may have been other events, changing the outcome of getProcessingDelay)
384
            ((cAsyncModule*) mod)->waitIfBusy();
385
            ((cAsyncModule*) mod)->setBusy();
379 386
            duration = ((cAsyncModule*) mod)->getProcessingDelay(this);
380 387
        }
381 388
    }

Also available in: Unified diff