Date: Sun, 2 Dec 2012 22:47:51 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Choupani <Choupani@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: protect common resources in kernel Message-ID: <alpine.BSF.2.00.1212022246160.18806@fledge.watson.org> In-Reply-To: <1354477696312-5766007.post@n5.nabble.com> References: <1354477696312-5766007.post@n5.nabble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1212022246160.18806>