Looks like an efficient and almost correct implementation of this,
yes.
One bug: you should use yield() instead of schedule() (2.5) or do
current->policy |= SCHED_YIELD;
before calling schedule (2.4). Or play it extra-safe and use a
traditional wait queue, even though this has more overhead.
> I get the feeling you already had something like this in mind, but your
> example above was rather complicated. The latter implementation is just
> standard reference counting.
Yup, my example was simply an approximation of the current module
code, with the obvious races fixed.
> With a standard reference counting implementation I don't see any of these
> issues being a problem..
Amazing, isn't it ? :-)
> Did I miss something?
I see two possible reasons why somebody may not want this solution:
- those wishing to squeeze the very last bit of performance out of
this may find holding the spin lock during the call a better
compromise than the reference counting
- in some cases, there could be a lock that's being held by the
caller of foo_deregister and that's also needed by
bar_whatever_op. In this case, you have to drop the lock while
waiting (or re-think the locking design).
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ - 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/