--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 06, 2005 at 08:41:02PM +0100, Jaromir Dolecek wrote:
> On Sun, Nov 06, 2005 at 12:47:09PM -0600, Eric Haszlakiewicz wrote:
> > On Sun, Nov 06, 2005 at 12:45:43PM -0600, Eric Haszlakiewicz wrote:
> > > 	The problem is that the only way you have to recognize that you're=
=20
> > > the intended target it with the userland address passed to sys_futex(=
).
> > > For this to work right, both proc's va's need to refer to the same
> > > underlying memory, so there should be either a vm_page or a vm_object
> >=20
> > er.. I meant vm_anon, not vm_page.
>=20
> vm_anon is per-process thing, so we don't want to use that -
> we need to use the vm_page or vm_object.

Why not just use vm_object?

Create a pool of sleep objects. A sleep object contains flags and an
offset. When a thread goes into sys_futex(), grab one and tie it to the
vm_object. Turn the slept-on address into an offset in (vm) object, store
it in the "sleep object" and sleep on the address of the sleep object.=20
When we do a wakeup, find the vm_object corresponding to the address and=20
calculate the offset within object. Then go looking for objects sleeping=20
on that offset, and wake it.

Do we know if sys_futex() makes any wakeup promises? As others have noted,=
=20
wakeup() can have spurious wakeups. If sys_fuxex() doesn't do that, then=20
we have to have something with a "yes, you really woke up" flag.

Take care,

Bill

--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDb5NpWz+3JHUci9cRAr/lAJ9p+t0vaRFGxUuvDavixH6MwErJcgCeKGL1
hNraGe4RJ12v+5PBtzEfBhg=
=rro+
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--