From owner-freebsd-threads@FreeBSD.ORG  Wed Nov  3 15:24:15 2004
Return-Path: <owner-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 55E1216A4CE; Wed,  3 Nov 2004 15:24:15 +0000 (GMT)
Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id E8B0143D3F; Wed,  3 Nov 2004 15:24:14 +0000 (GMT)
	(envelope-from deischen@freebsd.org)
Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11])
	iA3FOAqO004496;	Wed, 3 Nov 2004 10:24:11 -0500 (EST)
Date: Wed, 3 Nov 2004 10:24:10 -0500 (EST)
From: Daniel Eischen <deischen@freebsd.org>
X-X-Sender: eischen@sea.ntplx.net
To: Mike Makonnen <mtm@identd.net>
In-Reply-To: <20041103141914.GA2095@rogue.acs.lan>
Message-ID: <Pine.GSO.4.43.0411031019050.9924-100000@sea.ntplx.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net)
cc: threads@freebsd.org
cc: John Baldwin <jhb@freebsd.org>
Subject: Re: More mono + libpthread breakage..
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Daniel Eischen <deischen@freebsd.org>
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Nov 2004 15:24:15 -0000

On Wed, 3 Nov 2004, Mike Makonnen wrote:

> On Tue, Nov 02, 2004 at 05:12:11PM -0500, John Baldwin wrote:
> > This kicks in with mono because mono wants to call
> > 'sem_post()' (which is supposed to be signal safe) from a signal handler, but
> > sem_post() calls pthread_mutex_lock() which dies with an assertion error
> > about already being on a syncq since _cond_wait_backout() didn't happen.
>
> Then the correct fix is for sem_post to disable signals around calls to
> pthread functions. There are *no* async-signal safe pthread functions.

No, the problem has already occurred when sem_post() is called.  A signal
occurs while blocked in pthread_cond_wait() but there is a race where the
thread doesn't get removed from the CV queue then calls sem_post() which
tries to requeue the thread on another synchronization queue.  Normally
when a signal interrupts a pthread_cond_wait(), the thread should get
removed from the CV queue before calling the signal handler but this
isn't happening.

I am curious to see whether the fix I suggested solves the problem.

-- 
Dan Eischen