linux-imx
Public
Source
committed 796cacdda78======================Lightweight PI-futexes======================We are calling them lightweight for 3 reasons: - in the user-space fastpath a PI-enabled futex involves no kernel work (or any other PI complexity) at all. No registration, no extra kernel calls - just pure fast atomic ops in userspace. - even in the slowpath, the system call and scheduling pattern is very similar to normal futexes. - the in-kernel PI implementation is streamlined around the mutex abstraction, with strict rules that keep the implementation relatively simple: only a single owner may own a lock (i.e. no read-write lock support), only the owner may unlock a lock, no recursive locking, etc.Priority Inheritance - why?---------------------------The short reply: user-space PI helps achieving/improving determinism foruser-space applications. In the best-case, it can help achievedeterminism and well-bound latencies. Even in the worst-case, PI willimprove the statistical distribution of locking related applicationdelays.The longer reply----------------Firstly, sharing locks between multiple tasks is a common programmingtechnique that often cannot be replaced with lockless algorithms. As wecan see it in the kernel [which is a quite complex program in itself],lockless structures are rather the exception than the norm - the currentratio of lockless vs. locky code for shared data structures is somewherebetween 1:10 and 1:100. Lockless is hard, and the complexity of locklessalgorithms often endangers to ability to do robust reviews of said code.I.e. critical RT apps often choose lock structures to protect criticaldata structures, instead of lockless algorithms. Furthermore, there arecases (like shared hardware, or other resource limits) where locklessaccess is mathematically impossible.Media players (such as Jack) are an example of reasonable applicationdesign with multiple tasks (with multiple priority levels) sharingshort-held locks: for example, a highprio audio playback thread iscombined with medium-prio construct-audio-data threads and low-priodisplay-colory-stuff threads. Add video and decoding to the mix andwe've got even more priority levels.So once we accept that synchronization objects (locks) are anunavoidable fact of life, and once we accept that multi-task userspaceapps have a very fair expectation of being able to use locks, we've gotto think about how to offer the option of a deterministic lockingimplementation to user-space.Most of the technical counter-arguments against doing priorityinheritance only apply to kernel-space locks. But user-space locks aredifferent, there we cannot disable interrupts or make the tasknon-preemptible in a critical section, so the 'use spinlocks' argumentdoes not apply (user-space spinlocks have the same priority inversionproblems as other user-space locking constructs). Fact is, pretty muchthe only technique that currently enables good determinism for userspace