|Anonymous | Login||2019-12-08 15:57 UTC|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000109||OMNeT++||simulation kernel||public||2009-10-08 13:20||2010-03-31 14:10|
|Target Version||Fixed in Version||4.1b4|
|Summary||0000109: Cached parameter values are not set correctly in datarate and delay channel|
|Description||setDatarate, setDIsabled and other setter do not work correctly if they are used in initilaize or finish method, because handleParameterChange does not work in these functions so the underlying cached values are not correctly updated.|
in the setters would solve this problem, altough it is somwhet sub optimal.
On Thu, Oct 8, 2009 at 1:56 PM, Patrick Haeflinger <[email protected]> wrote:
That's exactly the problem !! what's confused me it the different indication given by Tkenv and "ev"
And yes I made this change of parameter in the "initialize()" method of my module to which the "cDatarateChannel" is connected to and thus the callback function is not called (as mentioned in the API)
According to the documentation I should invoke the "handleParameterChange()" method, but this method is protected, so I cannot call it from my calling module (which is not a subclass of CDatarateChannel) !!
So it seams a bit complicated from that point of view to change the value of the datarate of such a channel from within the C++ code without re-defining it !!
Do you have any suggestion for making this update ?
Actually, I think this is an issue with the kernel that should be fixed. Nobody would expect that setting the datarate with the setDatarate method is not working in the init function. There is an explicit setter method. It is nowehere documented, that it is not working in th init method. Its just an implementation detail, that we were using the parameter and the callback to refresh the cached value...
Anyway, we will fix this for the next version. Until then I would suggest patching the code in sim/cDatarateChannel.cc and sim/cDelayChannel.cc and in each setter (setDisabled, setDelay, setBitErrorrate(), setDatarate etc), call rereadPars() i.e it would look like this:
void cDatarateChannel::setDatarate(double d)
I will add a bugtracker entry for this.
Rudolf Hornig a écrit :
The datarate parameter is cached in the channel for better performance. If you update a parameter, there is a callback (handleParameterChange, which re reads the parameter).
The getDatarate function and the channel itself uses the cached value, while Tkenv displays the value of the parameter itself. So the issue seems that the handleParameterChange callback is not called...
Further checking the the docs of handleParameterChange
it came to my mind: do you happen to change the parameter value in your init function? If yes, then according to the docs the callback is not called, so you will really end up with the described situation (i.e. different parametervalue and cached value)?
On Wed, Oct 7, 2009 at 9:54 AM, Patrick Haeflinger <[email protected]> wrote:
I would like to redefine the "datarate" of a channel from my C++ code and I have the following behavior :
The DatarateChannel is defined in my ned file and fixed to a given value 'X'
Now when I try to change this datarate value from the C++ code in the following way :
cDatarateChannel *chan = check_and_cast<cDatarateChannel *>(gate("out")->getChannel());
chan->setDatarate(nbSrc*srcDataRate); // assume that Y=nbSrc*srcDataRate
The value displayed in tkenv mode by the object inspector correctly displays this new calculated value "Y" !
The simulation take into account the value of the ned defined one namely the "X" value
Now when I try to read again from the channel the newly setted value "Y" in my C++ code with :
ev << chan->getDatarate() << endl;
It will show me the value of the NED settings (value X), which is not in line with what the object inspector shows me !!!
I am not able to find out where I made a mistake !?
|Tags||No tags attached.|
|After some discussion: The correct solution would be to call the handleParametersChange() even during the init and finalize stages. Also add a note to the documentation that the order in which init is called in different modules are undefined.|
|Changed the behavior of the handleParameterChange() notification. It is called now always if the parameter's owner component is in initialized state... in your specific case this is true, because all channels are initialized by the time the module initialization starts (and there is only one init stage). In addition, handleParameterChanged(NULL) is called automatically by the kernel at the end of component initialization, so even if a parameter was changed during initialization phase, the module/channel will get a chance to refresh its cached values after the init phase has finished.|
|2009-10-08 13:20||rhornig||New Issue|
|2009-10-08 13:22||rhornig||Status||new => confirmed|
|2009-10-09 09:52||rhornig||Note Added: 0000178|
|2010-03-31 14:10||rhornig||Note Added: 0000220|
|2010-03-31 14:10||rhornig||Status||confirmed => resolved|
|2010-03-31 14:10||rhornig||Fixed in Version||=> 4.1b4|
|2010-03-31 14:10||rhornig||Resolution||open => fixed|
|2010-03-31 14:10||rhornig||Assigned To||=> rhornig|
|Copyright © 2000 - 2019 MantisBT Team|