Date: 15 Nov 2001 20:26:45 +0100
From: Dag-Erling Smorgrav <des@ofug.org>
To: Robert Watson <rwatson@FreeBSD.ORG>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alfred Perlstein <bright@mu.org>, Greg Lehey <grog@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Peter Wemm <peter@wemm.org>, freebsd-arch@FreeBSD.ORG
Subject: Re: cur{thread/proc}, or not.
Message-ID: <xzpg07f6dje.fsf@flood.ping.uio.no>
In-Reply-To: <Pine.NEB.3.96L.1011115135118.1877C-100000@fledge.watson.org>
References: <Pine.NEB.3.96L.1011115135118.1877C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@FreeBSD.ORG> writes: > The implicit question behind that, though, is: are there places in the > kernel that will always be locked into using curproc/curthread, simply due > to the structure and behavior of the kernel environment. There's a number of cases here: 1) the thread in question is curthread, and it is locked. 2) the thread may be any thread, but it is locked. 3) the thread may be any thread, and is not locked. (am I correct in assuming that curthread is *always* locked in code called from syscalls?) In some cases it doesn't make sense to assume anything but 1), because it is the case in 99% of the situations where the code is invoked and assuming 2) or 3) would involve a severe performance penalty for the common case. Copyin() is one example of this; for the rare cases where you need to copy data from a non-current thread's address space (mainly ptrace() and procfs), there is proc_rwmem(). In some cases it is desirable for an API to handle non-current threads. In those cases, it is the responsibility of the API functions to make sure the thread they're manipulating is properly locked. In some cases it is desirable for an API to handle non-current threads, but assume that the thread is locked, to save the overhead of mutex operations. In those cases, the code should be protected by mutex assertions. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpg07f6dje.fsf>