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