From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 00:12:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 019D616A4B3; Sun, 26 Oct 2003 00:12:58 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A0AE43F3F; Sun, 26 Oct 2003 00:12:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) h9Q7CuiF034677; Sun, 26 Oct 2003 00:12:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id h9Q7CuSv034676; Sun, 26 Oct 2003 00:12:56 -0700 (PDT) (envelope-from dillon) Date: Sun, 26 Oct 2003 00:12:56 -0700 (PDT) From: Matthew Dillon Message-Id: <200310260712.h9Q7CuSv034676@apollo.backplane.com> To: Robert Watson References: cc: John-Mark Gurney cc: hackers@freebsd.org cc: Kip Macy cc: Marcel Moolenaar Subject: Re2: Synchronization philosophy (was: Re: FreeBSD mail list etiquette) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 07:12:58 -0000 :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