Paul Menage wrote: > On Tue, Jul 29, 2008 at 7:09 PM, Pavel Emelyanov <xemul@xxxxxxxxxx> 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 > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
