History | View | Annotate | Download (17.4 KB)
Renamed duration -> eventDuration
Problem: We had a variable cMessage::duration for Horizon and avariable cPacket::duration from OMNeT++ itself while cPacket inheritsfrom cMessage. This might lead to the wrong variable being accessedby packets.
Solution: Renamed the Horizon variable cMessage::duration in...
Moved cAsyncModule functionality to cSimpleModule, dropped cAsyncModule
We eliminated the need for special cAsyncModule objectssince it is more convenient to just stick to cSimpleModule in themodel implementation and active Horizon through omnetpp.ini switches....
[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....
[core] implemented thread-safe(r) FES ordering
[eefscheduler] added changes from codereview (minor stuff) and moved scheduler call again from cSimulation to Tkenv and Cmdenv respectively
[eefscheduler] encapsulated getProcessingDelay-call in the getEventDuration() of cMessageThe duration of a message is invalidated in scheduleAt and sendDirect/Delayed
[eefscheduler] solved initialization bug of t_start- now using delivd instead of t_start (t_start was redundant to delivd)- removed t_start from code- some code cleanup (some debug output removed..)
Initial import of Horizon 4 release.