From owner-freebsd-questions Thu Sep 13 7:11:48 2001 Delivered-To: freebsd-questions@freebsd.org Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by hub.freebsd.org (Postfix) with SMTP id 06AD637B405 for ; Thu, 13 Sep 2001 07:11:42 -0700 (PDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu Sep 13 10:10:03 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Thu Sep 13 10:10:21 EDT 2001 Received: from mflasterpcmh (mflaster-pcmh.research.bell-labs.com [135.104.47.91]) by aura.research.bell-labs.com (8.9.1/8.9.1) with SMTP id KAA08269; Thu, 13 Sep 2001 10:09:42 -0400 (EDT) From: "Michael Flaster" To: , "Tor. Egge@fast. no" Cc: "Eran Gabber" , "Jeff Fellin" Subject: RE: Linux threads loses signal Date: Thu, 13 Sep 2001 10:09:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <200109131302.JAA17386@zydeco.research.bell-labs.com> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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