Provided Interfaces (PIs)

The case of PIs is similar in context to synchronous modeling tools's code: the available functionality that corresponds to the PI must be invoked; therefore, all that is required is an entry function into the PI, that takes the required parameters as function arguments.

There is an important difference, however, when comparing asynchronous code to synchronous code: OUT parameters are not allowed in PIs provided by APLCs that are modeled in asynchronous tools. By definition, OUT parameters are supposed to be "ready" at the end of the PI invocation; in contrast, asynchronous tools give no such guarantee - there is no way to know when the output (if any) is ready, except by waiting for the state machine inside them to respond by generating a message (and possibly, switching current state).

This is where synchronous and asynchronous tools diverge - and hence, the corresponding "glue" also diverges: in asynchronous tools, the responses are not OUT parameters; the responses are callbacks into the VM, which are in fact invocations of RIs. This is how asynchronous tools provide answers; they call back RIs (through the VM), and provide their output as the input parameters to these RIs.

Here is an example of the relevant AADL section for an asynchronous PI:

SUBPROGRAM tcommand
FEATURES
        hltc:IN PARAMETER DataView::T_HLTC_PLUS {encoding=>UPER;};
END tcommand;

SUBPROGRAM IMPLEMENTATION tcommand.SDL
PROPERTIES
        FV_Name => "basic_fv";
        Source_Language => OG; -- Modeled in ObjectGeode
END tcommand.SDL;

When the VM needs to invoke a PI that is implemented with an asynchronous modeling tool, it must invoke a bridge function, named...

void
FV_Name_SubPrgName(
    char *pInBuffer1, int iBufferSize1, 
    char *pInBuffer2, int iBufferSize2, 
    ...);

As with the synchronous tools, SubPrgName is the name of the SUBPROGRAM, and FV_Name is the additional AADL property set in the SUBPROGRAM IMPLEMENTATION section. Any non alpha-numeric characters in these names are replaced by '_'. Depending on the number of parameters expected by the PI, the procedure can have 0, 2, 4, or generally, 2xN arguments. For each PI input parameter, two arguments appear in the procedure: a pointer to the ASN.1 encoded data of the parameter, and a length (how many bytes the pointer points to).

These bridge functions are generated inside vm_if.c (which is automatically generated for each asynchronous PI, during the "glue" generation process).