Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Dec 2001 23:43:42 -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:  <20011212074342.GB4677@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:
> 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

[/me thinks]

...

Hmmm, whether this solves the problem and keeps it marked as PS_SUSPENDED,
I don't really know since I'm pretty much a neophyte at pthreads internals,
but I'm hoping that I articulate the problem clear enough that you can
find a more direct fix for this problem.

The thing that I don't see in that logic is how it can restore the
PS_COND_WAIT state before the suspend attempt. I'd normally think that
"thread->suspended = SUSP_COND_WAIT" would be needed so that it can be
remarked PS_COND_WAIT when a resume operation is requested. I don't see
how it can be put into that state in the other parts of the pthreads library
or if that's a relevant consideration.

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?20011212074342.GB4677>