Known limitations in current implementations for futex

[StevenJiang1110]

There are two main limitations in futex now.

• The futex requires the atomic load/store while loading/storing value. Currently, we simply use read_bytes/write_bytes instead of atomic operations. We should implement atomic read/write with atomic instructions.
• Set the correct key for futex word

Following the implementation in occlum, now kxos uses the virtual address as futex key to mark different futex words. In kernel, all futex words are stored in a key-value map(HashMap or BtreeMap), so we can get the exact futex word given a futex key(virtual address, for occlum). Occlum only has one address space, so the virtual address is unique for each futex word. In kxos, each process has an individual address space. The same futex word can be at different virtual addresses for different processes( futex manual ).

Like the above figure, process 1 and 2 may share futex words on different virtual addresses but same physical addresses. Process needs to know the exact futex word when it performs futex wake, which means waking up futexes waiting on the same futex word. Using virtual address to mark different futex words seems not to be a choice.

There can be two possible choices.

1. Use physical address as the key to mark different futex words, since the physical address of futex word is fixed. But for now, the kxos-frame API does not expose the physical address.
2. Still use virtual address. This depends on how we implement shared memory. Futex words are placed in shared memory. If shared memory are mapped to same virtual address for all processes, then virtual address is enough.

[tatetian]

The atomic load is not a real problem, at least for now. In most architecture, reading a 32-bit integer is an atomic operation. Even the atomicity or ordering is not set correctly, it only causes problems for futex in certain race conditions. And it is quite easy to fix; we can simply add load_u32 and store_u32, which takes an Ordering argument.