From owner-freebsd-threads@FreeBSD.ORG Thu Apr 17 22:56:02 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66BDE37B401 for ; Thu, 17 Apr 2003 22:56:02 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5821B43FAF for ; Thu, 17 Apr 2003 22:56:00 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HLDQQVJH; Fri, 18 Apr 2003 13:41:49 +0800 Message-ID: <002f01c3056f$6d9b7840$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Fri, 18 Apr 2003 13:57:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 05:56:02 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: 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