From owner-freebsd-threads@FreeBSD.ORG Thu Mar 10 13:58:49 2005 Return-Path: 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 E0DAF16A4CE for ; Thu, 10 Mar 2005 13:58:49 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id A746043D31 for ; Thu, 10 Mar 2005 13:58:49 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id DB70F46B11; Thu, 10 Mar 2005 08:58:48 -0500 (EST) Date: Thu, 10 Mar 2005 13:56:28 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Antoine Brodin In-Reply-To: <20050226144511.25262941.antoine.brodin@laposte.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_sem.c X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 13:58:50 -0000 On Sat, 26 Feb 2005, Antoine Brodin wrote: > Robert Watson wrote: > > On Fri, 25 Feb 2005, Antoine Brodin wrote: > > > > > I think you forgot to increment i, maybe you should replace > > > sem_array[i] = ks; by sem_array[i++] = ks; ? And the " + 1" in the > > > KASSERT looks bogus too ;). > > > > Antoine, > > > > As usual, good eyes :-). I tested the loop code, and then proceeded > > to change other things, and neglected to run the test case afterwards. > > By the way, I'm not sure a race with other threads in the parent process > can happen during fork(): thread_single() is called at the beginning of > fork1() if the parent process has had threads and thread_single_end() is > called at the end. Perhaps a thread guru can confirm this. I've broadened the CC to include threads@ because I'm not entirely sure of the semantics of the single threading mechanism in kernel -- specifically, how it behaves in the presence of 1:1 threads. Just to provide a bit more context for those on the list -- uipc_sem.c does some paperwork at fork() time so the parent and child processes both have references to the same set of semaphores. The way this is done right now is that the thread in kernel calling fork takes a snapshot of the set of semaphores, bumping their reference counts, then goes off and adds them to the child which involves potentially sleeping memory allocation. Under the assumption that other threads in the parent might still be executing, I address the issue through the snapshot and then assign the references owned by the snapshop array to the child process as the memory allocation takes place. This adds some overhead, which would be nice to get rid of -- if the snapshot is unnecessary. So the question is -- will the parent process see any parallelism in kernel during fork() for any of our threading model, or do we prevent that? Robert N M Watson