TASTE bugtrack - Taste
View Issue Details
0000259Taste[All Projects] Generalpublic2011-11-29 16:492014-10-17 07:03
user2 
 
normalfeaturehave not tried
newopen 
0000259: 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: 1 One httpserver component with: a. A PI for document request (equivalent to the GET/PUT method). Let's call it httprequest. This PI has one parameter: the http method (GET/PUT) and the requested address b. A RI to the client to receive the document (http content that would be processed by the browser) 2. One browser component with : a. A RI to the httprequest interface of the server b. A PI to receive http content from the server, let's call it httpretrieve. This PI has only one parameter which is basically an array of bytes, with the document to be printed by the browser. 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: a. A PI for document request (equivalent to the GET/PUT method). Let's call it httprequest. this PI has one IN parameter ( request parameters : put/get method, address, ...) and one OUT parameter (the result of the request). 2. One browser component with : a. A RI to the httprequest interface of the server 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: 1. What would be the constraints ? I suggest in that case that a sporadic PI can only have ONE IN parameter and zero or several OUT parameters 2. Define the semantics of out: is it supposed to be synchronuous calls or async calls ? 3. Mapping to the runtime: how this is mapped ? If this is synchronuous calls, we can imagine that no runtime support is made and that buildsupport does everything by its own, only by adapting the system through the vertical transformation process. For example, the CV would introduce PI in the back of the user to the service request. Then, the glue code will issue the request on the server and wait answer on its own PI with server request. 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.
No tags attached.
Issue History
2011-11-29 16:49user2New Issue
2011-11-29 22:25huguesNote Added: 0001400
2011-11-30 13:26user2Note Added: 0001403
2011-11-30 13:35huguesNote Added: 0001404
2011-11-30 14:32user2Note Added: 0001405
2014-10-17 07:03maximeSeverityminor => feature

Notes
(0001400)
hugues   
2011-11-29 22:25   
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
(0001403)
user2   
2011-11-30 13:26   
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 : 1. Sporadic threads that provides PI with OUT ports: WAIT -[IN data received]-> CALL APPLICATION CODE -> SEND DATA -> WAIT 2. Task that performs a RI with OUT parameters SEND-> [WAIT FOR INCOMING DATA] -> CONTINUE EXECUTION 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 ...
(0001404)
hugues   
2011-11-30 13:35   
We could support both mechanisms, as long as we can tell the user when not to use one of them. Note that MAST supports synchronous remote procedure calls (from their transactional model), so the analysis is possible, yet pessimistic. So the issue is to know wether we can to support it or not Out of curiosity, you mentioned HTTP, but are there some services that would benefit from synchronous calls, e.g. as part of PUS?
(0001405)
user2   
2011-11-30 14:32   
That is ok for me in that case. Just for precision, it would be used for SOIS. In SOIS, you can have a service to read a file. So, you have a sporadic function that waits for a request. The request can be : create/delete/read/writea file. In case of reading , the request will pass a buffer, the sporadic task will receive the request, fill the buffer and send the reply with the content. If you want to have a look at the standard: http://cwe.ccsds.org/sois/default.aspx [^] 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 ...