From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 04:55:21 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9013816A4D0 for ; Fri, 11 Jun 2004 04:55:21 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BCCA43D1D for ; Fri, 11 Jun 2004 04:55:21 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B4tJ6x005705; Fri, 11 Jun 2004 00:55:19 -0400 (EDT) Date: Fri, 11 Jun 2004 00:55:19 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086928888.38487.18.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 04:55:21 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote: > > > > The critical section should prevent the signal handler > > from being invoked. Put some printf()'s in after the > > sem_post() and in the signal handler(). The signal > > handler printf()'s should always occur after the sem_post(). > > Plus, you shouldn't be getting that signal since it > > should be masked until sigsuspend() is called. > > > > Is it getting past sem_post() and into sigsuspend() or not? > > If it is getting past sem_post(), then I don't think that is > > your problem. > > Here is what I see: > > master thread calls pthread_kill with SIGUSR1 and waits on semaphore. > other thread gets signal and calls sem_post. It yields the scheduler. This is fine as long as this thread doesn't get a signal until after sem_post(). Being signal safe doesn't mean that other threads can't be scheduled. > master thread gets semaphore and continues on it's way. > master thread calls pthread_kill with SIGUSR2 and keeps going. It can't keep going if there is a possibility that it can send the same thread another SIGUSR2. > Later, master calls pthread_kill with SIGUSR1 and waits on semaphore. > other thread gets signal and calls sem_post. It yields the scheduler. Why is it getting SIGUSR1? It is waiting for SIGUSR2, not SIGUSR1. You need to mask SIGUSR1 before the sem_post() and until after the sigsuspend() on SIGUSR2. > master thread gets semaphore and continues on it's way. > master thread calls pthread_kill with SIGUSR2 and keeps going. > Finally, master scheduler is done and yields the scheduler. > other thread gets to run now and then it goes into sigsuspend waiting > for SIGUSR2, but it never gets it because it wasn't masked until > sigsuspend is called. > threads are all hung. > > The problem is that sem_post should not cause a reschedule of threads > when inside a signal handler and it does. Nope, that is allowable. Please don't confuse signal safe with "will not yield the CPU". Also, on SMP, there are not guarantees regardless! I'm not saying that there isn't a bug somewhere, but don't go reading more into what the requirements of sem_post() are. -- Dan Eischen