I don't think your current patch is very useful.
It's obviously slower, and while it is an interesting approach for not
just lock generation but also for synchronization points, it doesn't seem
to actually _buy_ you anything. And since the cookie isn't guaranteed to
be unique, you can't actually use it as a synchronization point on its
own, but must always still have some shared memory location as a
confirmation for whatever the synchronization was.
Finally, waitqueue's (to me) always were about two big points:
- natural race condition avoidance through ordering:
current->state = sleeping;
add_wait_queue();
if (test)
schedule();
which you basically emulate with the "zero cookie" thing.
- ability to wait on multiple events concurrently
which you don't take any advantage of at all.
So you kind of missed the second big point of waitqueues, so the end
result really isn't any more fundamentally powerful than the (faster)
specialized semaphore system call as far as I can tell.
In short, I would argue that this approach, while interesting, doesn't
actually _buy_ you anything.
Now, if you want to wake on any of N events, then a "add_wait_queue*N +
wait" approach actually makes sense. But quite frankly, once you are there
you should really instead do full events, and go away and work together
with Ben on the aio stuff instead of this.
So: interesting approach, but in its current form pointless as far as I
can see.
Linus
-
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/