Execution order of mdlStart in a C MEX S-Function with SS_OPTION_PLACE_ASAP flag differs in R2019b compared to previous releases

We use a block that initiates shared memory with our product in its mdlStart function. As it has to be always called before all other mdlStarts of the other blocks, we used the following line at the end of mdlInitializeSizes for this block:

ssSetOptions(S, SS_OPTION_PLACE_ASAP | SS_OPTION_ALLOW_CONSTANT_PORT_SAMPLE_TIME | SS_OPTION_USE_TLC_WITH_ACCELERATOR);

This worked well with all previous MATLAB versions. However with 2019b, we noticed that the execution order of the different mdlStart functions is not influenced anymore by this flag. Meaning some blocks will have their mdlStart function called before, and as they need an initialized shared memory, nothing works anymore.

By putting traces in dummy blocks, I could observe that the execution order of mdlOutputs is still right. However, for mdlStart and mdlTerminate, this is not the case anymore.

Is this a change in 2019b? I could not find anything about it in the release notes. If so, is there a way we can enforce execution order of the mdlStart/mdlTerminate functions?

Answer 1

[MathWorks Support Team]

Since R2019b, we have introduced task-based sorting. In task-based sorting, the model is partitioned into different tasks based on the sampling times. Execution of the blocks inside each task is scheduled independent of the other tasks. Therefore, the flag SS_OPTION_PLACE_ASAP only affects the execution order of the S-Function with respect to the other blocks in the same task group. In the sample model, one S-function has continuous sample time, while the other one has constant sample time (infinite). Therefore, they belong to different tasks. You can see this by overlaying the execution order (block1 belongs to task 0 and block2 belongs to task 1):

As they belong to different tasks, the flag 

SS_OPTION_PLACE_ASAP

 does not affect the ordering between the two blocks. To ensure that the flag takes effect we need to force the blocks to be part of the same task. For instance, if we change the output sample time of block2 to continuous, both blocks will become part of the same task and the flag will take effect:

ssSetOutputPortSampleTime( S, 0, mxGetInf()); → ssSetOutputPortSampleTime( S, 0, CONTINUOUS_SAMPLE_TIME);

Changing the sample time of the S-Function which is supposed to initialize the shared memory (to ensure it is in the same task group with the other blocks) is a supposed workflow here.