From owner-freebsd-net@FreeBSD.ORG Sun Dec 2 22:47:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB02E61C for ; Sun, 2 Dec 2012 22:47:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7926F8FC14 for ; Sun, 2 Dec 2012 22:47:52 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 2B9F946B2A; Sun, 2 Dec 2012 17:47:52 -0500 (EST) Date: Sun, 2 Dec 2012 22:47:51 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Choupani Subject: Re: protect common resources in kernel In-Reply-To: <1354477696312-5766007.post@n5.nabble.com> Message-ID: References: <1354477696312-5766007.post@n5.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1806727502-1354488472=:18806" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 22:47:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1806727502-1354488472=:18806 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 2 Dec 2012, Choupani wrote: > I'm working on kernel in FreeBSD-9. I need to protect a > common resource (for example a queue). > There are 4 points for access (read/write) this common resource as bellows: > 1. ether_input() – hardware interrupt > 2. ip_input() & ip_output() – software interrupt > 3. dev_ioctl() – local io control in our own kernel module > 4. another kernel thread > > Which scenario is proper to use for this purpose: > > 1. kernel mutex (MTX_DEF) > 2. kernel mutex (MTX_SPIN) > 3. kernel share/exclusive lock > 4. kernel reader/writer lock Hi Choupani: Assuming you are not accessing the resource from a low-level interrupt handler ("filter") or within the scheduler, your best bets are (1) or (4), depending on whether you think you will benefit from read-locking as opposed to just write-locking. (2) should be avoided unless in the low-level interrupt/scheduler context, as it takes additional overhead (disabling interrupts, etc), and (3) can't be used in contexts were unbounded sleeping isn't allowed (e.g., from ithreads, within most parts of the lower network stack). Robert --621616949-1806727502-1354488472=:18806--