On Sun, 8 Sep 2019, Ayrat Gaskarov wrote:
> mutex_lock()
> function_to_lock()
> some_really_slow_not_observable_function()
> mutex_unlock()
>
> How could we avoid this? For example if
> some_really_slow_not_observable_function is long running loop using
> only local variables.
One possibility is by tying control flow and data flow in the inline asm.
Suppose your some_really_slow_not_observable_function returns an int, then
int ret = some_really_slow_not_observable_function();
asm volatile ("" :: "g"(ret), "X" (&mut) : "memory");
mutex_lock(&mut);
func_under_lock();
mutex_unlock(&mut);
<use ret>
enforces order by creating a dependency between the value returned from
the first call and mutex state used in the following call. A similar barrier
can be placed between the unlock and the use of 'ret':
asm volatile ("" : "=g"(ret) : "X" (&mut) : "memory");
(in general empty volatile asms with non-empty constraints is a nice tool for
limiting what the compiler may do)
Alexander
