libpthread patch

David Xu davidxu at freebsd.org
Thu Apr 17 22:56:02 PDT 2003


----- Original Message ----- 
From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
To: "David Xu" <davidxu at viatech.com.cn>
Cc: <freebsd-threads at 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.
> 
Good!

> There are a few issues we've got to go over, as well as
> looking closely at any locking order problems.
> 
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?
> 

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:
> 
> /*
> * Enter a loop to wait until we get the lock.
> */
> ts.tv_sec = 0;
> ts.tv_nsec = 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 = _kse_critical_enter();
> __sys_nanosleep(&ts, NULL);
> _kse_critical_leave(crit);
> 
> /*
> * 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);
> 
> 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.
> 
> Hmm, perhaps we can have a parameter on kse_release to specify
> whether we want a normal return or a new upcall.
> 
> 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.
> 

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.

> -- 
> Dan Eischen

David Xu




More information about the freebsd-threads mailing list