Date: Sun, 26 Oct 2003 00:12:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <rwatson@freebsd.org> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re2: Synchronization philosophy (was: Re: FreeBSD mail list etiquette) Message-ID: <200310260712.h9Q7CuSv034676@apollo.backplane.com> References: <Pine.NEB.3.96L.1031026001054.74063I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Again, I think it comes down to the fact that memory allocation APIs
:typically offer choices to the consumer: block if the resources aren't
:available, or fail. My mood swings a bit back and forth as to what the
:ideal strategy would/should be at the lowest level, but I think as you
:move up the stack, the exact semantics at the bottom matter less. The
:APIs are generally clear, but it's the programming layered on top of it
:that's sloppy (alternatively: at the bottom level API, the behavior is
:well-documented, but as you move up the stack, the behavior typically
:becomes more poorly documented). While it's probably appropriate to say
:"this is a property of poor programming, or at least, programming done
:against a model that we want no longer to hold true", there's still the
:issue of cleaning up the legacy code...
:
:Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
:robert@fledge.watson.org Network Associates Laboratories
Oh, and I just realized... particularly in the case of 5.x, I have
noticed that the vnode and lockmgr *INTERLOCK* mutexes seem to present
a severe blocking/synchronization problem for coders. There is a lot
of code in 5.x which must obtain and hold the interlock in order to
guarentee that the lockmgr operation that is about to be executed with
LK_NOWAIT will, in fact, not wait (on the interlock). Yowzer!
I'd consider that a serious problem because it interferes directly with
the abstraction that LK_NOWAIT is supposed to provide. The problem is
even more severe due to the 5.x's other little quirks like kernel
thread preemption by non-interrupts and cpu migration.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310260712.h9Q7CuSv034676>