Date: Fri, 18 Apr 2003 13:57:43 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <002f01c3056f$6d9b7840$f001a8c0@davidw2k> References: <Pine.GSO.4.10.10304180111270.25495-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20
From: "Daniel Eischen" <eischen@pcnet1.pcnet.com>
To: "David Xu" <davidxu@viatech.com.cn>
Cc: <freebsd-threads@freebsd.org>
Sent: Friday, April 18, 2003 1:22 PM
Subject: Re: libpthread patch
> I tried to rework this based on your idea of doing it at
> thread allocation time. I just committed it.
>=20
Good!
> There are a few issues we've got to go over, as well as
> looking closely at any locking order problems.
>=20
I have ever tried to port some kernel code to userland (e.g
mutex and witness), but now they were left there for
several days without be touched.
> One thing, which I think you agreed to some weeks/months ago,
> was to have the kernel set flag in the KSE mailbox in the
> kse_exit() system call. This is so the UTS can know that
> the KSE and it's stack is truly done. I've got some code
> in thr_kern.c that is commented out and is expecting that
> this will get done. Is that still something we can do?
>=20
I think you can use kse_wakeup for exiting kse, if the kse is
no longer used by kernel, kse_wakeup will return ESRCH, it is
not perfect, but should work.
> One other thing. Is there a way to wake up a KSE without
> having an upcall? For instance, in _kse_lock_wait(), we
> do something like this:
>=20
> /*
> * Enter a loop to wait until we get the lock.
> */
> ts.tv_sec =3D 0;
> ts.tv_nsec =3D 1000000; /* 1 sec */
> KSE_SET_WAIT(curkse);
> while (_LCK_BUSY(lu)) {
> /*
> * Yield the kse and wait to be notified when the lock
> * is granted.
> */
> crit =3D _kse_critical_enter();
> __sys_nanosleep(&ts, NULL);
> _kse_critical_leave(crit);
>=20
> /*
> * Make sure that the wait flag is set again in case
> * we wokeup without the lock being granted.
> */
> KSE_SET_WAIT(curkse);
> }
> KSE_CLEAR_WAIT(curkse);
>=20
> Can it be woken with kse_wakeup() or possible kse_thr_interrupt()
> (on a KSE mailbox) so that the nanosleep just returns? I used
> nanosleep, because kse_release() will force a new upcall.
>=20
> Hmm, perhaps we can have a parameter on kse_release to specify
> whether we want a normal return or a new upcall.
>=20
> I know that you have a patch for KSEs that never want to
> have an upcall, but that wouldn't work for this case where
> we want the KSE to upcall normally.
>=20
the patch http://people.freebsd.org/~davidxu/kse_release.diff
may be what you want.
there is two flags you can dynamically set/clear in km_flags,
they are not static, it means you can change them at runtime.
KMF_NOUPCALL
tell kernel to not schedule an upcall for blocked syscall
or for kse_release(), this too can be used to poll completed
context without restarting from upcall entry.
KMF_NOCOMPLETED
tell kernel to not bring completed context back to userland
when doing upcall. if you set KMF_NOUPCALL at same time, it
can be used for a kse trying to get a lock in critical section
where it can not process additional work.
> --=20
> Dan Eischen
David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002f01c3056f$6d9b7840$f001a8c0>