From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:02:09 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 7321716A4CE for ; Fri, 11 Jun 2004 05:02:09 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D00743D46 for ; Fri, 11 Jun 2004 05:02:06 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MRDA90F1; Fri, 11 Jun 2004 13:01:55 +0800 Message-ID: <40C93D60.3040003@freebsd.org> Date: Fri, 11 Jun 2004 13:04:32 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <1086924733.65671.81.camel@server.mcneil.com> In-Reply-To: <1086924733.65671.81.camel@server.mcneil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 05:02:09 -0000 Can you provide some code to demostrate the problem ? I have interest. David Xu Sean McNeil wrote: > I'm working on kse support for gcc/gcj/gij and ran into an interesting > problem with signals: > > Each thread installs a signal handler for synchronization. This signal > handler does a sem_post() to inform it has suspended then goes into a > sigsuspend() loop waiting for a signal that has no handler attached to > it. So we have > > SIGUSR1 - signal handler attached to suspend the thread > SIGUSR2 - no signal handler but waited on in sigsuspend() within the > above handler. > > When you want to have exclusive access, you loop through and stop each > thread by sending the SIGUSR2 and wait on the semaphore it posts to. > Then you do your thing. When done, you signal each thread with SIGUSR2. > > The problem I'm seeing is that the signal handler doesn't have > pririority thus it goes to sleep on the sem_post and the SIGUSR2 signal > is lost because it happens before the sigsuspend() is invoked. > > I think there is something missing or not functioning in sem_post that > should prevent the signal handler from losing the cpu. I see there is > an enter/exit critical in there. Should that prevent it from context > switching? It would appear not in that exiting a critical section will > cause a yield. > > Any help on figuring out how to fix this would be appreciated. Perhaps > someone more familiar with kse can tell me how to go about changing it > so that a signal handler cannot cause a yield. Perhaps something in > _thr_sig_handler? > > TIA, > Sean > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >