Date: Thu, 13 Sep 2001 10:09:13 -0400 From: "Michael Flaster" <mflaster@lucent.com> To: <freebsd-questions@FreeBSD.ORG>, "Tor. Egge@fast. no" <Tor.Egge@fast.no> Cc: "Eran Gabber" <eran@research.bell-labs.com>, "Jeff Fellin" <jkf@research.research.bell-labs.com> Subject: RE: Linux threads loses signal Message-ID: <PKEMKEJNABCHKGGJJIKJOEJNCAAA.mflaster@lucent.com> In-Reply-To: <200109131302.JAA17386@zydeco.research.bell-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the reply Tor. In my version of the code, I had to change
condvar.c:
static int
pthread_cond_timedwait_relative_old(pthread_cond_t *cond,
pthread_mutex_t *mutex,
const struct timespec * abstime)
{
volatile pthread_descr self = thread_self();
sigset_t unblock, initial_mask;
int already_canceled = 0;
// int was_signalled = 0;
int was_signalled = 1;
sigjmp_buf jmpbuf;
pthread_extricate_if extr;
This change fixed the problem - thanks!
I take it it's safe in this function to always assume that a restart signal
was received? I assume there are just some performance inefficiencies? The
relevant code is:
if (!was_signalled) {
...
}
__pthread_set_own_extricate_if(self, 0);
...
pthread_mutex_lock(mutex);
return 0;
Mike
----- Begin Included Message -----
>From Tor.Egge@fast.no Wed Sep 12 21:28 EDT 2001
From: Tor.Egge@fast.no
To: jkf@research.bell-labs.com
Cc: freebsd-questions@FreeBSD.ORG
Subject: Re: Linux threads loses signal
In-Reply-To: Your message of "Wed, 12 Sep 2001 16:43:52 -0400 (EDT)"
References: <200109122043.QAA23910@zydeco.research.bell-labs.com>
Date: Thu, 13 Sep 2001 03:28:27 +0200
Sender: Tor.Egge@fast.no
Content-Type: Multipart/Mixed;
boundary="--Next_Part(Thu_Sep_13_03:25:13_2001)--"
Content-Length: 1597
X-Lines: 45
> We have an application using the linuxthreads package, version 2.1.3_2,
> installed on FreeBSD 4.3. The application occassionally gets blocked
> waiting in pthread_cond_timedwait_relative_old(), at least from the
> stack trace. There are many threads, 13, in the application each calling
> pthread_cond_timedwait. We have been unable to recreate the problem
> in a smaller program, since we don't understand what is happening in
> the linuxthreads library with cond_timedwait.
The thread is probably restarted before it reduces the resume count in
__pthread_timedsuspend_old(), thus no signal is sent by
__pthread_restart_old().
> Does any one have ideas on what the problem might be and/or a fix?
Try the enclosed patch. It causes __pthread_timedsuspend_old() to
assume that a restart signal has already been delivered if the resume
count wasn't atomically reduced from 0 to -1 in the first if
statement.
- Tor Egge
----- End Included Message -----
----------
X-Sun-Data-Name: "files/patch-ab"
X-Sun-Encoding-Info: 7bit
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 11
--- pthread.c.OLD Wed Sep 12 23:28:16 2001
+++ pthread.c Thu Sep 13 00:12:15 2001
@@ -947,7 +947,7 @@
__pthread_timedsuspend_old(pthread_descr self, const struct timespec
*abstime)
{
sigset_t unblock, initial_mask;
- int was_signalled = 0;
+ int was_signalled = 1;
sigjmp_buf jmpbuf;
if (atomic_decrement(&self->p_resume_count) == 0) {
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?PKEMKEJNABCHKGGJJIKJOEJNCAAA.mflaster>