|Anonymous | Login | Signup for a new account||2019-10-19 14:27 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000259||Taste||[All Projects] General||public||2011-11-29 16:49||2014-10-17 07:03|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
Support for OUT parameters on sporadic interfaces
This is not a bug but more likely a discussion about potential improvements about the component model of TASTE. At that time, a sporadic operation can have only one IN operation. So, when you want to have an answer (client/server model), you have to specify one provided interface on the service provider and one PI on the service requester.
For example, if we want to map the HTTP protocol in TASTE, we have to make two components:
The problem in that case is that for each component that may receive an httpdocument, it has to define a PI to retrieve it. On the other hand, allowing OUT parameter on the sporadic interface would be better: in that case, we could have only:
1 One httpserver component with:
In that waym we avoid defining a PI on each component that may use this interface.
But on the other hand, we have to discuss several points regarding that:
So, once again, this bug report is more a general discussion and before implementing anything, it would be useful to discuss, especially because people like Jerome or Maxime have an experience on middleware and could potentially indicate what would be potential issues about implementing this.
|Tags||No tags attached.|
Julien, the semantics you describe is (AFAICT) the semantics of inout AADLv2 port, or CORBA two-way (synchronous) request/reply.
I think it is better (at AADL level) to support it this way: one inout port, with a type being a union, for the in direction, use one part of the union, for the out direction, use the other part. This would make things easier to process at code generation level. These ports were never implemented for the reasons below.
The reply has to be synchronous, if not it will become tricky to model it in AADL. In CORBA, they use callback for the asynchronous case, but this makes the code really noisy to read: you have to split at code-level sending from receiving, which is counter-intuitive in many cases.
For the records, bidirectionnal interactions were forbidden during ASSERT because it breaks many assumptions of the RCM. So this should be designed carefully.
The problem is the following: suppose a sporadic thread that is entering a bidir interaction. Then this thread has two point of suspension: the wait for event, the wait for the answer. This fundamentally breaks RCM which allows just one suspension point.
In your example, you indicate using HTTP, so breaking RCM is not a big deal for this protocol. It would become if you want to allow it for more constrained systems
Ok, so, I was wondering if this would break the RCM model and now, I see and understand the problem. I think we night consider several things.
Your TASTE sporadic thread (we don't talk about the mapping to AADL right now, I think it is out of the scope of this discussion - at least for this moment) will have ONLY one IN parameter. And will ALWAYS wait for this incoming event. In other words, it means that you have only one interruption point (the IN parameter). Receiving the data from the request is considered as part of the application code.
If this is not enough precise, I think we can consider the sporadic thread as a state machine. It will act as the following :
The fact is that the [WAIT FOR INCOMING DATA] state for RI that may call PI with OUT parameters is not a suspension point as a sporadic event : it is part of the application code. In terms of schedulability, you have to consider the time required to get the OUT values in the execution time.
However, I see also the problem it can cause from a theoric point of view: in that case, the WCET would not reflect the processing time but a large estimation of execution time, leading to a very pessimist execution time. In that case, we can also issue a warning to the user when he designed such systems to indicate that network communication time has to be included in the WCET and so, may lead to incorrect results.
After all, there is also another solution which consists in considering the reply as a other sporadic event to be received by the task. But in that case, it also introduces some errors : you have to provide a mechanism to identify the reply according to the request (because you don't know if the reply come from the previous request or the one you did 3 minutes ago ...), you directly break scheduling assumptions (but we can deal with that and propose a message to the user). I think that by waiting automatically after sending the request is the KISS method and would be the most used. However, as stated, this is an open bug and we can also imagine that we can support both mechanisms ...
We could support both mechanisms, as long as we can tell the user when not to use one of them.
Out of curiosity, you mentioned HTTP, but are there some services that would benefit from synchronous calls, e.g. as part of PUS?
That is ok for me in that case.
I will try to propose an implementation of SOIS within TASTE, so, we would need to introduce new services in polyorb, but not that much ...
|2011-11-29 16:49||user2||New Issue|
|2011-11-29 22:25||hugues||Note Added: 0001400|
|2011-11-30 13:26||user2||Note Added: 0001403|
|2011-11-30 13:35||hugues||Note Added: 0001404|
|2011-11-30 14:32||user2||Note Added: 0001405|
minor => feature
|Copyright © 2000 - 2011 MantisBT Group|