Subject: Re: map user memory in kernel
To: Emmanuel Dreyfus <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 11/06/2005 11:46:53
On Sun, Nov 06, 2005 at 09:36:09AM +0000, Emmanuel Dreyfus wrote:
> On Sun, Nov 06, 2005 at 08:19:18AM +0000, David Laight wrote:
> > With a single global sleep address you would wakeup A, you'd also wakeup
> > process C sleeping on an entirely different futex - but the code in C
> > should verify that the event it is waiting for has happened.
> There is still the problem to recognize address X in process A being the
> sa?e as address Y in process B.
But we always have this problem within the kernel with sleeps. You always
have to be ready, when you're woken up, to check that you were actually the
intended target of the wakeup -- select() is a notorious example where we
traditionally had a lot of collisions (did we add wakeup1() to deal with
this? SunOS did). Is there some reason this won't work for futex?
I think you're going to end up using less distinct addresses to wait on
than you might hope, with this approach, because data structures that the
process sleeps on will obey alignment constraints, and if I understand what
futex is used for correctly, they may also often be _the same structure_
allocated at the same point in the run of multiple callers, so the offset
into many callers' pages may be the same. Still, it's simple and should
get you going, if you can figure out what to check after wakeup but before
putting the target process back on the run queue.
Thor Lancelot Simon email@example.com
"The inconsistency is startling, though admittedly, if consistency is to be
abandoned or transcended, there is no problem." - Noam Chomsky