[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2] rwlock: allow recursive read locking when already locked in write mode
- To: Jürgen Groß <jgross@xxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 21 Feb 2020 16:27:36 +0100
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Fri, 21 Feb 2020 15:27:41 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 21.02.2020 16:23, Jürgen Groß wrote:
> On 21.02.20 16:17, Jan Beulich wrote:
>> On 21.02.2020 16:13, Jürgen Groß wrote:
>>> On 21.02.20 15:51, Julien Grall wrote:
>>>> You are assuming that atomic_t will always be:
>>>>
>>>> struct
>>>> {
>>>> int counter;
>>>> }
>>>>
>>>> What if we decide to turn into
>>>>
>>>> struct
>>>> {
>>>> bool a;
>>>> int counter;
>>>> }
>>>
>>> As said before: then queue_write_lock_slowpath() is already broken.
>>
>> Why? The atomic_*() used would still only act on the counter field
>> (for their actual operation, i.e. what matters to callers; the
>> other field(s) could be statistics or whatever).
>
> No:
>
> u32 cnts;
> ...
> if ( !(cnts & _QW_WMASK) &&
> (atomic_cmpxchg(&lock->cnts, cnts,
> cnts | _QW_WAITING) == cnts) )
I must be blind then. As said, atomic_cmpxchg() would still (for the
purpose of consuming "cnts") act on only the "counter" field. It may
additionally e.g. increment a stats counter.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
