Nick Piggin wrote:
Corey Minyard wrote:
Arjan van de Ven wrote:
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).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...
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
