Date: Thu, 25 May 2006 10:47:50 -0700 From: Jason Evans <jasone@FreeBSD.org> To: Kurt Miller <kurt@intricatesoftware.com> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: pthread_cond_signal w/suspended threads Message-ID: <4475EDC6.10508@FreeBSD.org> In-Reply-To: <200605251049.34486.kurt@intricatesoftware.com> References: <200605241814.11452.lists@intricatesoftware.com> <Pine.GSO.4.64.0605241900060.29100@sea.ntplx.net> <200605251049.34486.kurt@intricatesoftware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4475EDC6.10508>