Jan Kiszka <[email protected]> 于2021年8月26日周四 下午9:28写道： > > On 26.08.21 11:40, Dongjiu Geng wrote: > > Hi, > > I see cpu_public->cpu_suspended is protected by spinlock, but I > > see there is no concurrency problem for the cpu_public->cpu_suspended. > > check_events() is the only place to change cpu_public->cpu_suspended > > variable， other CPU can not change is variable, also check_events() > > is > > not preempted in the current CPU, because IRQ is masked in the current > > CPU. So there is no need to add spin_lock for > > cpu_public->cpu_suspended variable. > > > > The lock protects (among other things) the consistent view on and > modifications of suspend_cpu and cpu_suspended. You have on CPU setting > suspend_cpu as a request and another CPU being the target, evaluating it > and setting cpu_suspended when actually having reached that state. > > You can't remove the lock without risking racing between the two CPUs. > Maybe not all of them will lead to inconsistent states, but some can, > and arguing that those will not happen in reality is much harder (if > possible at all) than placing these locks here.
Understand it now, thanks a lot for the clarification. > > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/CABSBigQRphzbxvzjcSyTvbChopJ3DM3wv2L0MgoxYrXJRf2u_g%40mail.gmail.com.
