ue main threads are missing subframes in hard real time conditions

An explanation of the UE bug, that we may also see in some other places.

/*

The server process waits events (signals) to perform a sub-frame processing

*/

UE processing thread () {

// There is several instances of this thread, but the bug is not related to parallel processing between these threads

// this mutex is dedicated to this thread instance

lock(mutexID)

until ( instance_count != "one instance running" )

    cond_wait(mutex_ID, cond_signal_ID) // the signal is also dedicated to this thread instance

// posix cond_wait free the mutex, do blocking wait the signal, relock the mutex (the entire process is atomic)

unlock(mutexID)

do_CPU_intensive_tasks();

lock(mutexID)

instance_count="no instance running"

unlock(mutexID)

}

/*

the client thread: a view of a huge if() combination on several pages in the function UE_thread

*/

while (true) {

do_receive_IQ_samples();

do_send_samples();

lock(mutexID);

complex_check(instance_count); // the purpose is to detect real time issues

instance_count="instance running";

cond_signal(mutexID, cond_signal_ID);

unlock(mutexID);

}

---

Mistake:

pure error:

this design allows to send signal while the thread UE processing thread() is doing it's processing

Posix signals are not queues: if there is no listener the signal is lost

not good:

instance_count is crossed managed between the two threads, over complex and almost useless

---

Consequence

Actual RF: we miss subframes processing where the cpu processing takes more time than what it should

Simulated RF: missing a subframe blocks the processing forever

---

Basic simulator work around: use the same signal cond_signal_ID to signal back from server thread to client thread

This works around is not fully working (it only works better, but it doesn't prevent to miss signals in severe CPU constrains)

---

Affected: UE 4G, UE nr, maybe some other multi-thread cases

---

Correct design, with raw posix signals

/*

The server process waits events (signals) to perform a sub-frame processing

*/

UE processing thread () {

// There is several instances of this thread, but the bug is not related to parallel processing between these threads

// this mutex is dedicated to this thread instance

lock(mutexID)

do ( ret = cond_wait(mutex_ID, cond_signal_ID) ) while ( ret )

do_CPU_intensive_tasks();

unlock(mutexID)

}

/*

the client thread: a view of a huge if() combination on several pages in the function UE_thread

*/

while (true) {

do_receive_IQ_samples();

do_send_samples();

timeout= choice(infinite time for RF simulators, 2ms for 4G (in case of two tandem processing threads), ...)

if ( lock_timed(mutexID) == timeout ) {

        log_error(missed real time constrains)

        continue; // a defense case to decide: what is the best workaround behavior?

}

cond_signal(mutexID, cond_signal_ID);

unlock(mutexID);

}