From owner-freebsd-arch Thu Nov 15 11:26:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DFF5537B405; Thu, 15 Nov 2001 11:26:48 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 0558414C2E; Thu, 15 Nov 2001 20:26:46 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Robert Watson Cc: Matthew Dillon , Alfred Perlstein , Greg Lehey , Bruce Evans , Peter Wemm , freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. References: From: Dag-Erling Smorgrav Date: 15 Nov 2001 20:26:45 +0100 In-Reply-To: Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson 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