From owner-freebsd-threads@FreeBSD.ORG Thu May 25 17:48:00 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 6285E16B1EE; Thu, 25 May 2006 17:48:00 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 141E643D4C; Thu, 25 May 2006 17:47:55 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id D3B225E492F; Thu, 25 May 2006 10:47:54 -0700 (PDT) Received: from [192.168.168.201] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 488315E4903; Thu, 25 May 2006 10:47:53 -0700 (PDT) Message-ID: <4475EDC6.10508@FreeBSD.org> Date: Thu, 25 May 2006 10:47:50 -0700 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.8-1.4.1 (X11/20060420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kurt Miller References: <200605241814.11452.lists@intricatesoftware.com> <200605251049.34486.kurt@intricatesoftware.com> In-Reply-To: <200605251049.34486.kurt@intricatesoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.5 Cc: Daniel Eischen , 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 17:48:07 -0000 Kurt Miller wrote: > On Wednesday 24 May 2006 7:07 pm, Daniel Eischen wrote: >>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. > > Sure, I agree. Right now the only alternative I see is > to not use pthread_suspend/resume_np and do thread > suspension with signals the way hotspot does it for > linux. I'd perfer not to do that if possible. If the code requires protection from suspension via critical sections, it turns out that there's a nearly free lazy approach if you use signal-based suspend/resume that is way cheaper than preventative locking. So, although the suspend/resume APIs are seductive, there are many situations in which they are actually a pessimization. Jason