Re: [RFC][PATCH 2/4] res_counter check usage under val

[Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>]

Paul Menage wrote:
> On Tue, Jul 29, 2008 at 7:09 PM, Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> wrote:
>>> I get your point. Logically this lock is unnecessary.
>>> (And seems this patch itself is buggy..(maybe refresh miss))
>>>
>>> BTW, I'm sorry if I misunderstand. unsigned long long (on x86-32)
>>> can be compared safely ?
>> Oops... Indeed.
>> That discourages me, that we need a spinlock for simple comparisons :(
>>
> 
> We could add a function to read a res_counter that only takes a
> spinlock on architectures where a 64-bit value can't be read
> atomically.

Agree.

BTW, I think it's a good candidate for some generic, I don't know, data
type? Or some helper like arch_prepare_long_read(), that is void on 64 
bit ones and some variant of seqcount (*count*, not seq*lock*) for 32.

> Also, for values that are monotonically increasing, I think it should
> be possible to read a 64-bit value without locking by checking that
> reading the value twice either side of an appropriate memory value
> returns the same result both times.
> 
> Paul
>