Re: [Xen-devel] [PATCH] spinlock: improve spin_is_locked() for recursive locks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.16 at 12:36, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Thu, Mar 24, 2016 at 4:19 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 24.03.16 at 16:55, <david.vrabel@xxxxxxxxxx> wrote:
>>> On 24/03/16 11:30, Jan Beulich wrote:
>>>> Recursive locks know their current owner, and since we use the function
>>>> solely to determine whether a particular lock is being held by the
>>>> current CPU (which so far has been an imprecise check), make actually
>>>> check the owner for recusrively acquired locks.
>>>
>>> What's the expected behaviour of _spin_is_locked() if the lock is held
>>> by another CPU?
>>>
>>> Before it may return true if it is held by another CPU, now it will
>>> always return false in this case.
>>
>> Correct - hence the reference to this only being used for a limited
>> set of cases (read: ASSERT()s and alike).
> 
> A bunch of the mm locks add "_by_me" at the end of the function.  Did
> spin_is_locked() used to have that as well?

I don't think it did. And I think the only other readily visible use
case of spin_is_locked() (testing whether a spin lock could be
acquired without delay) is bogus anyway, as it would better be
performed by doing a try-lock.

> In any case I suppose "spin_is_locked_by_someone()" is really pretty
> useless information.

Indeed, hence I didn't want to alter the functions' names.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel