0000109: Cached parameter values are not set correctly in datarate and delay channel

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000109

OMNeT++

simulation kernel

public

2009-10-08 13:20

2010-03-31 14:10

Reporter

rhornig

Assigned To

rhornig

Priority

high

Severity

major

Reproducibility

always

Status

resolved

Resolution

fixed

Platform

OS Version

Product Version

4.0

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.

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/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)
{
par("datarate").setDoubleValue(d);
rereadPars();
}

I will add a bugtracker entry for this.
Rudolf

Thank's

Patrick

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
http://www.omnetpp.org/doc/api/classcComponent.html#2c290c145b8c16e2de68def880659506 [^]

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

Rudolf

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

Patrick

Tags

No tags attached.

Attached Files

Relationships

Notes
(0000178) 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.

(0000220) 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