qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] Introduce RCU-enabled DQs (v2)


From: Mike Day
Subject: Re: [Qemu-devel] [RFC PATCH] Introduce RCU-enabled DQs (v2)
Date: Sun, 25 Aug 2013 09:06:06 -0400
User-agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/24.2.1 (x86_64-redhat-linux-gnu)

Paolo Bonzini <address@hidden> writes:

> Just a couple of questions, one of them on the new macro...
>
>> +/* prior to publication of the elm->prev->next value, some list
>> + * readers  may still see the removed element when following
>> + * the antecedent's next pointer.
>> + */
>> +
>> +#define QLIST_REMOVE_RCU(elm, field) do {                       \
>> +    if ((elm)->field.le_next != NULL) {                         \
>> +       (elm)->field.le_next->field.le_prev =                    \
>> +        (elm)->field.le_prev;                                   \
>> +    }                                                           \
>> +    atomic_rcu_set((elm)->field.le_prev, (elm)->field.le_next); \
>> +} while (/*CONSTCOND*/0)
>
> Why is the barrier needed here, but not in Linux's list_del_rcu?
>
> I think it is not needed because all involved elements have already been
> published and just have their pointers shuffled.

I read this as more than shuffling pointers. The intent here is 
that the previous element's next pointer is being updated to omit the
current element from the list.

atomic_set always deferences the pointer passed to it, and
(field)->le_pre is a double pointer. So looking at the macro:

#define atomic_set(ptr, i) ((*(__typeof__(*ptr) *volatile) (ptr)) = (i))

It translates to: 

( ( * (__typeof(*elm->field.le_prev) *volatile) (elm)->field.le_prev)  = 
elm->field.le_next; ) 

Which is: 

 *((struct *elm) *volatile)(elm)->field.le_prev = elm->field.le_next; 

Which is:

*(elm)->field.le_prev = elm->field.le_next;

Because field.le_prev is a double pointer that has previously been set
to &prev (the address of the previous list element) this is assiging the
*previous* element's next pointer, the way I read it.

The Linux list_del_rcu is dealing with a singly linked list and
therefore does not set a value in the previous node's element. 

But I'm still unclear on whether or not the memory barrier is needed
because the deleted element won't be reclaimed right away.

Mike

-- 

Mike Day | + 1 919 371-8786 | address@hidden
"Endurance is a Virtue"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]