From owner-freebsd-arch@FreeBSD.ORG  Fri Oct 15 06:14:43 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1561116A4CE; Fri, 15 Oct 2004 06:14:43 +0000 (GMT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 9F10243D55; Fri, 15 Oct 2004 06:14:42 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9F6EYwQ080109;
	Thu, 14 Oct 2004 23:14:39 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200410150614.i9F6EYwQ080109@gw.catspoiler.org>
Date: Thu, 14 Oct 2004 23:14:34 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: ssouhlal@FreeBSD.org
In-Reply-To: <1C45EA64-1D5B-11D9-A525-000A95C4D7BC@FreeBSD.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: freebsd-arch@FreeBSD.org
Subject: Re: [RFC] sysctl locking
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Oct 2004 06:14:43 -0000

On 13 Oct, Suleiman Souhlal wrote:

>> What happens if:
>> 	thread A owns an oid
>>
>> 	thread B, which wants to delete the oid, goes to sleep to wait
>> 	for the oid
>>
>> 	thread C wants the oid and goes to sleep
>>
>> 	thread A releases the oid and wakes up thread B
>>
>> 	thread B deletes the oid
>>
>> 	thread C does ???
> 
> I didn't think of this possibility. I guess I'll have to rethink the 
> whole thing, whenever I find some time.

Have thread B mark the oid as deleted and disconnect it from the tree.
When any subsequent waiting threads gain ownership, have them return
ENOENT if they see the deleted flag instead of calling the handler.
Free the oid when the last waiting thread gives up ownership.