livelock encountered in RTOS

We have ported mimalloc (ver. 1.6.7) to VxWorks. One issue we encountered was a livelock situation in a single core environment. VxWorks is a RTOS with priority based scheduling. The issue manifested when process A was resetting a heap page state (in _mi_free_block_mt()) but then preempted by a higher priority process B before the state transition was completed. Process B attempted to allocate memory from the same heap page (), it entered a busy loop awaiting the expected page state. Process B continued to get the CPU time given its higher priority. Process A did not get to run to complete the page state transition and hence, process B got stuck in the busy loop. This is particularly problematic in a single core environment with VxWorks (with multi-core, process A and B can run in different cores and run independently to avoid the locking condition as long as they are not assigned the same core) and there is no satisfactory route on the OS side to address this. For now, the VxWorks approach is to do a minimum delay in mi_atomic_yield() when the condition occurs which is not desirable from priority based scheduling perspective.

Start by reading _mi_free_block_mt() and mi_atomic_yield(), then trace the heap-page state transition and the allocation busy loop described for VxWorks. Reproduce or reason about the single-core priority-preemption sequence; done means avoiding the livelock without relying on an undesirable minimum delay.

Written by the indexing model from the issue text.