OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000109OMNeT++simulation kernelpublic2009-10-08 13:202010-03-31 14:10
Assigned Torhornig 
PlatformOSOS Version
Product Version4.0 
Target VersionFixed in Version4.1b4 
Summary0000109: Cached parameter values are not set correctly in datarate and delay channel
DescriptionsetDatarate, 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.

Adding rereadPars();
in the setters would solve this problem, altough it is somwhet sub optimal.
Additional Information

On Thu, Oct 8, 2009 at 1:56 PM, Patrick Haeflinger <[email protected]> wrote:
Hi Rudolf,

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/ and sim/ 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 :
Hi Patrick,

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:
Hi all,

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 !?


TagsNo tags attached.
Attached Files

- Relationships

-  Notes
rhornig (administrator)
2009-10-09 09:52

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.
rhornig (administrator)
2010-03-31 14:10

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.

- Issue History
Date Modified Username Field Change
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 - 2022 MantisBT Team
Powered by Mantis Bugtracker