On Mon, Jun 20, 2016 at 8:56 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 18.06.16 at 01:12, <dario.faggi...@citrix.com> wrote:
>> Yet another situation very similar to 779511f4bf5ae
>> ("sched: avoid races on time values read from NOW()").
>>
>> In fact, when more than one runqueue is involved, we need
>> to make sure that the following does not happen:
>> 1. take the lock of 1st runq
>> 2. now = NOW()
>> 3. take the lock of 2nd runq
>> 4. use now
>>
>> as, if we have to wait at step 3, the value in now may
>> be stale when we get to use it at step 4.
>
> Is this really meaningful here? We're talking of trylocks, which don't
> incur any delay other than the latency of the LOCKed (on x86)
> instruction to determine lock availability.
This makes sense to me -- Dario?
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
