Date: Wed, 09 Jun 2004 20:14:34 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bosko Milekic <bmilekic@FreeBSD.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/kern kern_proc.c Message-ID: <57189.1086804874@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 09 Jun 2004 18:06:42 -0000." <20040609180642.GA33304@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20040609180642.GA33304@freefall.freebsd.org>, Bosko Milekic writes: > While this idea is initially appealing, you should be aware that > it is not as straight-forward as it sounds. > > Namely, it is sometimes more advantageous to protect the manipulation > of the reference count within a section of code already protected by > an appropriate object mutex, and other times (in the absence of a mutex), > it might be more advantageous to use atomic ops (no need for a mutex, > slightly less costly per-instance). So defining an API that does one > OR the other might not always be appropriate. A still hot from the oven example of this is the code I just added in kern/tty.c: ttyrel() needs to do more locking than ttyref() because it might unlink the tty from a TAILQ whereas ttyref() will never touch the TAILQ. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57189.1086804874>