Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 May 2006 19:07:30 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        kurt@intricatesoftware.com
Cc:        freebsd-threads@freebsd.org
Subject:   Re: pthread_cond_signal w/suspended threads
Message-ID:  <Pine.GSO.4.64.0605241900060.29100@sea.ntplx.net>
In-Reply-To: <200605241814.11452.lists@intricatesoftware.com>
References:  <200605241814.11452.lists@intricatesoftware.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0605241900060.29100>