But it would be a real pain to add asm volatile for every possible
variable and computations that were previously (and after) done (may
be even from callers up a stacktrace). Could we somehow avoid this?
вс, 8 сент. 2019 г. в 23:48, Alexander Monakov <amonakov@xxxxxxxxx>:
>
> 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
--
Gaskarov Bros. Studio
