Skip site navigation (1)Skip section navigation (2)
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>