Date: Tue, 11 Dec 2001 23:06:55 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: 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: <Pine.SUN.3.91.1011211224444.6320B-100000@pcnet1.pcnet.com> In-Reply-To: <20011212012218.GA3199@gnuppy>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Dec 2001, Bill Huey wrote:
> On Tue, Dec 11, 2001 at 06:12:37PM -0500, Daniel Eischen wrote:
> > > 3) The waiting queue recalculation stuff seems to be logically ok, but
> > > was also sloppily glued together. I only marginally care for the
> > > same reason as above. ;-)
> >
> > Not sure why this is needed. In general, wait times are in absolute
> > times and blocking conditions internal to the threads library should
> > be able to handle errant wakeups (so they don't return to the caller).
> > This is essential for signal handling to work properly. If a thread
> > waiting on a mutex or condition variable has to handle a signal, it
> > needs to dequeue itself from the mutex/cv queue, run the signal handler,
> > and then it returns to the mutex or cv routine (which detects the
> > errant wakeup, requeues the thread, and calls the scheduler to block
> > and schedule another thread again).
>
> Maybe a different kind of suspend operation is needed or the semantics
> of how I interpreted it should be different in that when the GC thread is
> run, that should block out and prevent any thread from running, changing
> state to waking until it's done with the collection. Maybe I should allow
> it to timeout and then only change state to PS_COND_WAIT, etc... at the
> point where it gets resumed.
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: */
--
Dan Eischen
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?Pine.SUN.3.91.1011211224444.6320B-100000>