Re: [PATCH] New operation for kref to help avoid locks

[Corey Minyard <minyard@acm.org>]

Nick Piggin wrote:

> Corey Minyard wrote:
>
>> Arjan van de Ven wrote:
>>
>>>> Just doing an atomic operation is not faster than doing a lock, an 
>>>> atomic operation, then an unlock?  Am I missing something?
>>>>   
>>>
>>>
>>>
>>> if the lock and the atomic are on the same cacheline they're the same
>>> cost on most modern cpus...
>>>  
>>>
>> Ah, I see.  Not likely to ever be the case with this.  The lock will 
>> likely be with the main data structure (the list, or whatever) and 
>> the refcount will be in the individual item in the main data 
>> structure (list entry).
>>
>
> Is get_with_check actually going to be useful for anything? It
> seems like it promotes complex and potentially unsafe schemes.

It is certainly more complex to use this, and I'm guessing that's why 
Greg rejected it.  Certainly a valid problem.

>
> eg. In your queue example, it would usually be better to have
> a refcount for being on queue, and entry_completed would remove
> the entry from the queue and accordingly drop the refcount. The
> release function would then just free it.

True.  But if things picked up entries of the queue and incremented 
their refcount, then you would need a lock.  The same technique would 
apply.  But your example would be the more common one, I would think.

Thanks,

-Corey