From owner-freebsd-java Tue Dec 11 23:34:10 2001 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (cx739861-a.dt1.sdca.home.com [24.5.164.61]) by hub.freebsd.org (Postfix) with ESMTP id 12F1637B41C for ; Tue, 11 Dec 2001 23:34:07 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.33 #1 (Debian)) id 16E3tv-0001Et-00; Tue, 11 Dec 2001 23:33:59 -0800 Date: Tue, 11 Dec 2001 23:33:58 -0800 To: Daniel Eischen Cc: Bill Huey , Nate Williams , absinthe@pobox.com, shanon loveridge , freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011212073358.GA4677@gnuppy> References: <20011212012218.GA3199@gnuppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 11, 2001 at 11:06:55PM -0500, Daniel Eischen wrote: > I don't understand what is wrong with pthread_suspend_np and > pthread_resume_np (not the suspend/resume that suspend all > threads). Suspending and resuming all should do the same as > suspending and resuming one, but for all threads except for > the current thread. > > If a thread is in a CV wait, its state is PS_COND_WAIT. If it > was in a timed wait, the thread's timeout is set accordingly (to > the absolute time). If the thread then gets suspended, the > suspension state gets set to SUSP_COND_WAIT indicating that it > is both suspended and in a CV wait. The thread should still > be in the waiting queue, so the scheduler will time it out if > the wakeup time elapses. If the thread timesout, then the > scheduler should see that it is suspended and not add it to > the run queue; it should also set the suspended state to > SUSP_NO. > > So it looks to me like the problem is that the scheduler is > waking up the thread and making it runnable before it is > resumed. Is that the case? Does the following look like > it might solve the problem? > > Index: uthread_kern.c > =================================================================== > RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v > retrieving revision 1.38 > diff -u -r1.38 uthread_kern.c > --- uthread_kern.c 4 May 2001 20:37:07 -0000 1.38 > +++ uthread_kern.c 12 Dec 2001 04:15:35 -0000 > @@ -387,6 +387,10 @@ > ((pthread->wakeup_time.tv_sec == ts.tv_sec) && > (pthread->wakeup_time.tv_nsec <= ts.tv_nsec)))) { > switch (pthread->state) { > + case PS_SUSPENDED: > + PTHREAD_WAITQ_REMOVE(pthread); > + pthread->suspended = SUSP_YES; > + break; > case PS_POLL_WAIT: > case PS_SELECT_WAIT: > /* Return zero file descriptors ready: */ Yes, this is roughly the problem that I'm talking about. The timeout operation in the waiting queue marks the thread PS_RUNNING without checking to see if it's already marked PS_SUSPENDED. It should check to see if it's PS_SUSPENDED, keep it suspended until a resume operation is requested. It currently wakes the thread regardless of this when it times out in the waiting queue which isn't what I'd like in a suspend all operation in it allows for threads to run when I want it to be completely stopped until the GC completes. The only logical case that something like this happens is in pthread_cond_timedwait(). Am I making sense ? bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message