Given the 64-bit timebase, add wait_until to Semaphore.
Naming is based on Thread::wait_until.
pthreads uses "timedwait", but that's not a good fit against our
existing wait() - pthreads only has an absolute-time wait, not relative.
Given the 64-bit timebase, add trylock_until to Mutex.
Naming is based on a combination of Mutex::trylock, Thread::wait_until,
and C++11 timed_mutex::try_lock_until.
pthreads and C11 use "timedlock", but that's not a good fit against our
existing trylock() and lock(timeout) - they have only absolute-time
waits, not relative.
To increase the similarity to C++11, add trylock_for - same parameters
as lock, but with the bool return value of trylock and trylock_until.
Add an assertion when convering status codes to booleans to check that
there are no non-timeout errors.
Given the 64-bit timebase, add wait_until to ConditionVariable.
Move the timeout example to wait_until(), and give wait_for() an
alternative example, as it's no longer the best option for a
timeout.
Tidy up - remove the redundant RESUME_SIGNAL definition.
Give C++ access to the RTOS's absolute timebase, reducing the need to
run private Timers and similar. Allows wait_until functionality, and
makes it easier to avoid time drift.
Place it in a new header and namespace in case we want more kernel
functions in future.
Try to cover over the breaking API change potentially upcoming in
CMSIS-RTOS 2.1.1, when it reduces the tick count from 64-bit to 32-bit.
(See https://github.com/ARM-software/CMSIS_5/issues/277)
Explicitly state that ticks are milliseconds in mbed OS, despite CMSIS
RTOS 2 permitting different tick rates.
See also https://github.com/ARMmbed/mbed-os/pull/3648 (wait_until
for condition variables) and
https://github.com/ARMmbed/mbed-os/issues/5378 (EventQueue should
use RTOS tick count).
Remove the assert that the tick count of the OS matches the tick
count of the tickless timer as this occurs frequently when
debugging. This is because the function svcRtxKernelResume
only increments the OS's tick count until the next wakeup event
so if the device was halted by a debugger past the next wakeup
event the tick counts will be out of sync.
Call to osThreadTerminate is guarded by local_id check, to avoid parameter error fault when deleting or terminating Thread object that was not started.
armcc fopen allocated a mutex using the retargeted system-level
_mutex_initialize function. Interestingly, malloc also uses this
same _mutex_initialization function, which prevents a full solution
relying on malloc. The solution previously implemented involved using
the rtx mutex pool for the first 8 mutexes, then falling back on
malloc.
The previous implementation relied on osMutexNew returning an error
on out-of-memory. An unrelated change causes osMutexNew to instead
assert (except for release mode). This meant if you exceed 8 system-
level mutexes in armcc you will hit an assert. Since the filesystem
code can call fopen an unlimited number of times, this is a problem.
Solution is to keep track of which static mutexes we've allocated, so
we know before calling osMutexNew if we need to call malloc.
Also _mutex_free never deallocated the malloced mutexes, which would
cause fopen to leak memory.
Various RTOS classes were storing their CMSIS-RTOS creation attribute
structure as a member, when it's not required after construction. Reduce
memory by eliminating this member.
uVisor doesn't set the PSP of the target thread. The RTOS sets the PSP
of the target thread from the target thread's TCB. However, when
interrupts of higher priority than PendSV happen between the call to
uVisor to switch boxes, and the RTOS setting PSP, the uVisor vIRQ
interrupt handler will attempt to use an invalid PSP (the PSP from
before the box and thread switch). This leads to a crash. Make box and
thread switching atomic by disabling interrupts immediately before the
box switching until immediately after the new PSP is set.
OsEventObserver objects expect a context to be maintained per thread on
their behalf. Add this context to the thread control block and extend
the thread creation functions with the ability to supply a context.
Add the OsEventObserver mechanism. A client interested in receiving
notifications on certain OS events can register to receive notifications
with osRegisterForOsEvents. This is useful for clients like the secure
memory allocator, which observes thread switching events in order to
swap in and out different memory allocator objects.
Senthil Ramakrishnan
Cruz Monrreal
Kevin Bracey
Russ Butler
Amanda Butler
Martin Kojtal
Maciej Bocianski
Bartek Szatkowski
Vladimir Umek
Robert Rostohar
Maciej Rogozinski
Christopher Haster
Jimmy Brisson
Jaeden Amero