[palladio-dev] [sdq-dev] Local variables in RD-SEFFs

Steffen Becker steffen.becker at uni-paderborn.de
Fri Aug 3 13:29:06 CEST 2012


Hi,

please consider that this has been defined as it is _intentionally_. 
SetVariableActions are not allowed to change any variable in the current 
stack frame and this is needed as otherwise dependency resolution would 
not work as it does today.

I agree that it could be renamed to SetOutVariableAction or similar (as 
it is not only Return it is also INOUT and OUT giving it a good name is 
difficult which lead us to just use SetVariable). Even for INOUT, 
however, it cannot override its current characterisations, it just can 
transfer new values to the caller but not change values in the current 
SEFF. Also in the caller, the local variables can only be assigned 
_once_. (DISCLAIMER: This is not checked in the automatic static 
semantics, but just documented! SimuCom probably could do such changes. 
However, again, this breaks dependency computation and the dynamic 
semantics as defined by the Coloured Petri Nets....

So, before you modify things here, make sure you understand all these 
consequences...

Best
Steffen

Am 03.08.12 12:21, schrieb Anne Koziolek (Martens):
> Hi all,
>
> I would not see an inconsistency:
>
> ExternalCallAction may set local variables so that subsequent actions
> within the same SEFF may depend on the outcome of calls.
>
> SetVariableActions (should be renamed SetReturnVariableActions) set
> return variables so that callees may depend on the outcome of a call.
>
> I guess the design rationale here is that this is the minimum to enable
> parametric dependencies on call results. You need to be able to assign
> local variable names to ExternalCallAction results so that you can have
> several ExternalCalls you depend on. You cannot use only references to
> ExternalCallActions within a Set(Return)VariableAction because some are
> not always executed (if they are in a branch).
>
> Cheers,
> Anne
>
> On 03.08.2012 11:44 Henning Groenda wrote:
>> Hi Jörg, hi Klaus,
>>
>> Indeed, using a component parameter is my favored workaround. However, the inconsistency of handling local variables still remains. I wanted to start a discussion on a neat and permanent solution.
>>
>> "Programming" in Palladio is prevented by the semantics and simulation, e.g. loop conditions cannot be modified from within a loop. If we have the concept of internal variables we should enable people to use it properly.
>>
>> Best regards,
>> Henning
>>
>> Am 03.08.2012 um 10:58 schrieb Jörg Henß:
>>
>>> Hi Henning and Klaus,
>>>
>>> perhaps you can solve your problem by using a component parameter as default when no result of an external call is available.
>>> In the OMNet++ variant of PCM the problem of semantics of elements is not solved, but less restrictions are made on the model as it is not meant for manual modeling.
>>>
>>> Best regards
>>> Joerg
>>>
>>>
>>>
>>>
>>> --
>>> ______________________________________________________________________
>>>
>>> Karlsruhe Institute of Technology (KIT)
>>> Faculty of Informatics
>>> Institute for Programme Structures and Data Organisation
>>> IPD Reussner - Software Design and Quality
>>>
>>> Dipl.-Inform. Jörg Henß
>>> Researcher
>>>
>>> Am Fasanengarten 5, Building 50.34, Room 325
>>> 76131 Karlsruhe, Germany
>>>
>>> Phone: +49 721 608-46796 (-45993, secr.)
>>> Fax: +49 721 608-45990
>>> Email: henss at kit.edu
>>> http://sdq.ipd.kit.edu/
>>>
>>> KIT - University of the State of Baden-Württemberg and National
>>> Laboratory of the Helmholtz Association
>>>
>>> Am 03.08.2012 um 10:50 schrieb Klaus Krogmann:
>>>
>>>> [switched to palladio-dev mailing list]
>>>>
>>>> Dear all,
>>>>
>>>> Palladio intentionally does not allow general local variables. Variables are only meant for modeling the data flow between control flow elements (Calls, ExternalCallActions, InternalActions, Branches, and SetVariableActions (i.e. setting the return parameter)).
>>>>
>>>> General local variables are excluded to avoid people starting to "program" in Palladio.
>>>>
>>>> Best regards,
>>>> Klaus
>>>>
>>>>
>>>> Am 03.08.2012 10:42, schrieb Henning Groenda:
>>>>> Hi Jörg,
>>>>>
>>>>> If you didn't have local variables you couldn't assign out parameters of calls because you would always overwrite existing variables. We'll have to keep that concept.
>>>>>
>>>>> Having an explicit ReturnAction (and separate SetVariableAction) would make it pretty easy to distinguish between local and return variables (if this is necessary). Code changes on the simulation would be minimal.
>>>>>
>>>>> Does OmNet++ solve the issue of the element's semantics? My question is how we have to adjust the semantic of metamodel elements and than the implementations.
>>>>>
>>>>> Best regards,
>>>>> Henning
>>>>>
>>>>> Am 03.08.2012 um 10:27 schrieb Jörg Henß:
>>>>>
>>>>>> Hi Henning,
>>>>>>
>>>>>> in my understanding the Palladio model does not allow to create "local" variables by intention.
>>>>>> I agree with you that perhaps the SetVariableAction should be renamed if we keep to that.
>>>>>> Perhaps we can do a BreakOut session on this topic
>>>>>>
>>>>>> Using the InternalCallActions (PALLADIO-32) might make it more elegant in contrast to ExternalCallActions…
>>>>>>
>>>>>> When using my OMNet++ implementation, you could do all this staff you want ;)
>>>>>>
>>>>>> Best regards
>>>>>> Joerg
>>>>
>>>> Am 03.08.2012 um 10:14 schrieb Henning Groenda:
>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> The handling of local variables is currently a bit inconsistent. ExternalCallActions may set _only_ local variables in their out-/returnparameter section. SetVariableActions may set _only_ return values and no local variables. As a result, modifications of local variables can only be made by ExternalCallActions. If the meaning of SetVariableAction is SetReturnParameterAction then the according construct should be introduced besides a SetVariableAction in my opinion.
>>>>>
>>>>> I can't see an advantage of this separation. The stack frame concept of the simulation prevents misuse (e.g. a loop in which the same variable is always multiplied by itself) anyway. The disadvantage is that ExternalCallActions must be used to set local variables.
>>>>>
>>>>> I have a use case in which a local variable is set depending on a cache hit/miss (either the local variable should be set or an external call is made to retrieve the value).
>>>>>
>>>>> Do you have any comment or solutions?
>>>>>
>>>>> Kind regards,
>>>>> Henning
>>>>
>
>
>

-- 
Jun.-Prof. Dr.-Ing. Steffen Becker

University of Paderborn                Phone:  (+49 5251) 60-3320
Heinz Nixdorf Institute                Fax:    (+49 5251) 60-3530
& Department of Computer Science       Office: ZM1.02-10
Software Engineering Research Group    E-Mail: steffen.becker at upb.de
Zukunftsmeile 1
33102 Paderborn
Germany



More information about the palladio-dev mailing list