Date: Tue, 11 Dec 2001 23:33:58 -0800 From: Bill Huey <billh@gnuppy.monkey.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Bill Huey <billh@gnuppy.monkey.org>, Nate Williams <nate@yogotech.com>, absinthe@pobox.com, shanon loveridge <shanon_loveridge@yahoo.co.uk>, freebsd-java@FreeBSD.ORG Subject: Re: Pthreads bug fix [was Re: jdk1.3.1p5] Message-ID: <20011212073358.GA4677@gnuppy> In-Reply-To: <Pine.SUN.3.91.1011211224444.6320B-100000@pcnet1.pcnet.com> References: <20011212012218.GA3199@gnuppy> <Pine.SUN.3.91.1011211224444.6320B-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011212073358.GA4677>