Description
The AUTOSAR OS has no support for the concept of actively 'yielding' a thread. when the task running the function Sciclient_serviceSecureProxy, SciClient waits for any previous calls to complete, it is in the running state. It would have to transition to the waiting state to actively release the CPU. Waiting can only be entered for extended tasks which are waiting for an event. Meaning something externally would need to trigger that event for it to re-activate. There is no mechanism other then this to release the CPU.

The idea is to replace the hard-coded single-thread syncing code in the function Sciclient_serviceSecureProxy with a flexible call-out Appl_SciClient_Critical_Start and Appl_SciClient_Critical_End, which can be implemented different for different OS-es. For an AUTOSAR OS these could 'lock a resource' while for SafeRTOS the existing implementation taken from this function could be used.

The requirement is to refactor the code into a separate file (library remains the same) so that it can be replaced.

Resolution

The critical section code in Sciclient_serviceSecureProxy() is refactored so that the customers of AUTOSAR can modify Sciclient_criticalSection_start(), Sciclient_criticalSection_end() according to the AUTOSAR specific calls for locking and releasing the resource. The functions Sciclient_criticalSection_start(), Sciclient_criticalSection_end() are put in sciclient_util.c instead of sciclient.c due to the safety qualification concerns.

Root Cause
The current implementation of critical section in Sciclient_serviceSecureProxy() is as follows:
Suppose a thread starts executing the code of Sciclient_serviceSecureProxy(), it then sets the variable gSciclient_writeInProgress to 1 and it continues the execution. Let us assume a higher priority thread arrives and this results in the preemption of the execution of previous thread. The higher priority thread executes the while loop and goes into sleep state when it hits Osal_delay() due to which it goes out of running queue and releases the CPU to the lower priority thread. Now, the lower priority thread completes its execution and then the CPU control will be transferred to the higher priority thread. But in AUTOSAR, Osal_delay() does not put the thread into sleep state. This results in the higher priority thread being stuck in the while loop and the lower priority thread also cannot execute because the higher priority thread has the control of the CPU. This results in busy waiting.