From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 02:41:25 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 8C7C916A4B3; Thu, 9 Oct 2003 02:41:25 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9C9F43FDD; Thu, 9 Oct 2003 02:41:22 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfl87.dialup.mindspring.com ([165.247.213.7] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A7XH9-000342-00; Thu, 09 Oct 2003 02:40:05 -0700 Message-ID: <3F852C7B.81133DDE@mindspring.com> Date: Thu, 09 Oct 2003 02:38:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: frank@exit.com References: <200310081536.h98FaFa1087800@realtime.exit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a434d8e57a3429c19af59236b412d246723ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: hsu@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. 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: Thu, 09 Oct 2003 09:41:25 -0000 Frank Mayhar wrote: > The other thing is that the unlocked reads about which I assume Jeffrey > Hsu was speaking can only be used in very specific cases, where one has > control over both the write and the read. If you have to handle unmodified > third-party modules, you have no choice but to do locking, for the reason > you indicate. On the other hand, you can indeed make such a rule as you > describe: For this global datum, we always either write or read it in a > single operation, we never do a write/read/modify/write. Hey, if it's > your kernel, you can make the rules you want to make! But it's better > to not allow third-party modules to use those global data. I'm pretty sure that Jeffrey is aware of read-modify-write issues with atomic vs. idempotent multi-instruction operations, since he generally knows what he's doing. 8-). Probably the most interesting cases, from his perspective in the network stack, are queue insertions and removals for singly linked queues, where the insertion OR removal can be done atomically without taking locks (but not both, except on fully MESI coherent systems without speculative execution). FreeBSD's use of queue structures is sometimes overkill, and the macro order of operations as they are currently defined prevent non-locking operations, even where they would be safe, if the order of operation were reversed (e.g. for a simple singly linked tail queue). -- Terry