Issue was seen with below example
EventQueue q1;
EventQueue q2;
void main() {
while( true ) {
q1.chain( &q2 ); // Chain q2 to q1
q1.chain( NULL ); // Remove chain from q1
//This second step should free the memory from the chained q2 event.
}
}
Memory allocated from q1 slab was freed for q2, which will result in
memory leak.
If user has initiated a delayed event (either with call_in or call_every),
user might need to know how much time is left until the event is
due to be dispatched.
Added time_left() function can be used to get the remaining time.
Event queue was using its own Timer or LowPowerTimer objects to derive
millisecond tick counts. This is unnecessary in RTOS builds, where the
RTOS is maintaining a tick count.
It also makes more sense to use the actual RTOS tick count, as the
values are being used to compute tick timeouts for RTOS calls. Computing
these RTOS tick delays with a separate timer could conceivably lead to
rounding errors.
Fixes: #5378
Building with (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 gives this warning
../events/equeue/equeue.c: In function 'equeue_incid':
../events/equeue/equeue.c:40:17: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
if (!(e->id << q->npw2)) {
Make calls to cmsis-os to get thread state, stack size, and max stack
usage rather than accessing internal RTX data directly. Wrap RTX5
specific code in OS_BACKEND_RTX5.
Also refactor the code to use mbed types rather than RTX types:
os_timer_t -> mbed_rtos_storage_timer_t
os_event_flags_t -> mbed_rtos_storage_event_flags_t
osRtxMutex_t -> mbed_rtos_storage_thread_t
To allow components with a simple need to schedule a few events to not
have to create their own threads, with all the associated memory
overhead, add 2 central calls to get shared normal and an
interrupt-deferral event queues, each dispatched on their own shared
threads.
For non-RTOS systems, just the normal event queue is provided, and the
application would have to dispatch this itself. This
application-dispatch is also available via a config option, to
potentially save memory by reusing the main thread.
Possible future improvement: the ability for separate components to
request a minimum stack size, and have the JSON combine these requests.
(Analogous tooling has already been mooted for mbed TLS config options
like key size).
This provides the correct binary semaphore behaviour that was expected
by the equeue layer, removes concerns around semaphore overflow, and
reduces the number of spurious wakeups which may save a bit of power.
This also fixes some issues we were seeing around the RTX 5 changes
to semaphore behaviour.