From owner-freebsd-threads@FreeBSD.ORG Wed May 24 23:07:32 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 E60A516A540 for ; Wed, 24 May 2006 23:07:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 446C443D58 for ; Wed, 24 May 2006 23:07:32 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k4ON7U2H003830; Wed, 24 May 2006 19:07:30 -0400 (EDT) Date: Wed, 24 May 2006 19:07:30 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: kurt@intricatesoftware.com In-Reply-To: <200605241814.11452.lists@intricatesoftware.com> Message-ID: References: <200605241814.11452.lists@intricatesoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: pthread_cond_signal w/suspended threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 23:07:34 -0000 On Wed, 24 May 2006, Kurt Miller wrote: > I've been working on an intermittent deadlock in > the jvm and have isolated it to the following issue. > When multiple threads are waiting on a condition > variable and some of those threads have been suspended > with pthread_suspend_np(), there is an expectation that > pthread_cond_signal() will signal an unsuspended thread > first. However, the following program shows this is not > the case on 6.1-release/kse (thr works as expected). > > Can kse behavior be changed to signal unsuspended > threads first? Relying on this behavior isn't exactly portable, and what if there are no unsuspended threads when the signal occurs. A suspended thread would still be signaled in that case. The whole suspended threads thing is kind of dangerous anyways. If one of these threads hold a lock, or is waiting in some other queue, then deadlock can occur. I think you need a way of waiting until they are out of critical regions before you suspend them in order for this not to cause problems. -- DE