> On Wed, 10 Oct 2001, Rusty Russell wrote:
>>
>> If noone *holds* a reference, you can remove it "sometime later",
>> where "sometime later" is (for example) after every CPU has scheduled.
> Ehh.. One of those readers can hold on to the thing while waiting for
> something else to happen.
> Looking up a data structure and copying it to user space or similar is
> _the_ most common operation for any lookup. You MUST NOT free it just
> because we scheduled away. Scheduling points have zero meaning in real
> life.
How does locking inside the kernel help you here ? You could face
the same situation even if you protect the data by locking.
Perhaps, I am missing something here. So, a specific example would help.
> So you'll need a reference count to actually keep such a data structure
> alive _over_ a schedule. Or all the readers need to copy the data too
> before they actually start using it. At which point you've made your code
> a _lot_ slower than the locking version.
Only relevant issue I can see here is preemption - if you hold
a reference and get preempted out it is still a context switch
and the logic of "when the data can be really deleted" must take
into account such context switches. Alternatively, you could
disable preemption while traversing such lists.
Thanks
Dipankar
-- Dipankar Sarma <dipankar@in.ibm.com> Project: http://lse.sourceforge.net Linux Technology Center, IBM Software Lab, Bangalore, India. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/