On 15/07/16 15:51, Paolo Bonzini wrote:
>
> On 15/07/2016 14:37, Sergey Fedorov wrote:
>> I understand why an implied wmb can be expected after the entry is
>> removed: so that the caller can trash the contents of the object
>> removed. However that would require double-check on lookup side to
On 15/07/2016 14:37, Sergey Fedorov wrote:
> On 13/07/16 14:13, Paolo Bonzini wrote:
>> diff --git a/include/qemu/qht.h b/include/qemu/qht.h
>> index 70bfc68..f4f1d55 100644
>> --- a/include/qemu/qht.h
>> +++ b/include/qemu/qht.h
>> @@ -69,6 +69,9 @@ void qht_destroy(struct qht *ht);
>> *
On 13/07/16 14:13, Paolo Bonzini wrote:
> diff --git a/include/qemu/qht.h b/include/qemu/qht.h
> index 70bfc68..f4f1d55 100644
> --- a/include/qemu/qht.h
> +++ b/include/qemu/qht.h
> @@ -69,6 +69,9 @@ void qht_destroy(struct qht *ht);
> * Attempting to insert a NULL @p is a bug.
> * Inserting
On 14/07/16 16:56, Paolo Bonzini wrote:
>
> On 13/07/2016 19:50, Sergey Fedorov wrote:
>> On 13/07/16 10:36, Paolo Bonzini wrote:
>>> On 13/07/2016 01:19, Emilio G. Cota wrote:
I wouldn't put those comments in the source--seqlock callers should
know what they're doing, and what barriers
On 13/07/2016 19:50, Sergey Fedorov wrote:
> On 13/07/16 10:36, Paolo Bonzini wrote:
>>
>> On 13/07/2016 01:19, Emilio G. Cota wrote:
>>> I wouldn't put those comments in the source--seqlock callers should
>>> know what they're doing, and what barriers seqlocks imply.
>> In general I'd agree
On 13/07/2016 20:03, Sergey Fedorov wrote:
> On 13/07/16 14:13, Paolo Bonzini wrote:
>>
>> On 12/07/2016 22:13, Sergey Fedorov wrote:
>>> diff --git a/include/qemu/qht.h b/include/qemu/qht.h
>>> index 70bfc68b8d67..5f633e5d8100 100644
>>> --- a/include/qemu/qht.h
>>> +++ b/include/qemu/qht.h
>>>
On 13/07/16 14:13, Paolo Bonzini wrote:
>
> On 12/07/2016 22:13, Sergey Fedorov wrote:
>> diff --git a/include/qemu/qht.h b/include/qemu/qht.h
>> index 70bfc68b8d67..5f633e5d8100 100644
>> --- a/include/qemu/qht.h
>> +++ b/include/qemu/qht.h
>> @@ -69,6 +69,9 @@ void qht_destroy(struct qht *ht);
On 13/07/16 10:36, Paolo Bonzini wrote:
>
> On 13/07/2016 01:19, Emilio G. Cota wrote:
>> I wouldn't put those comments in the source--seqlock callers should
>> know what they're doing, and what barriers seqlocks imply.
> In general I'd agree with you, however in this case the "begin" calls
> are
On 12/07/2016 22:13, Sergey Fedorov wrote:
> diff --git a/include/qemu/qht.h b/include/qemu/qht.h
> index 70bfc68b8d67..5f633e5d8100 100644
> --- a/include/qemu/qht.h
> +++ b/include/qemu/qht.h
> @@ -69,6 +69,9 @@ void qht_destroy(struct qht *ht);
> * Attempting to insert a NULL @p is a bug.
>
On 13/07/2016 01:19, Emilio G. Cota wrote:
> I wouldn't put those comments in the source--seqlock callers should
> know what they're doing, and what barriers seqlocks imply.
In general I'd agree with you, however in this case the "begin" calls
are what implements QHT's guarantee *for the
On Tue, Jul 12, 2016 at 23:13:36 +0300, Sergey Fedorov wrote:
> From: Sergey Fedorov
> It is naturally expected that some memory ordering should be provided
> around qht_insert(), qht_remove(), and qht_lookup(). Document these
> assumptions in the header file and put some
From: Sergey Fedorov
It is naturally expected that some memory ordering should be provided
around qht_insert(), qht_remove(), and qht_lookup(). Document these
assumptions in the header file and put some comments in the source to
denote how that memory ordering requirements
12 matches
Mail list logo