From owner-freebsd-smp@FreeBSD.ORG Tue Sep 16 19:48:07 2003 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2DF616A4B3 for ; Tue, 16 Sep 2003 19:48:07 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F99743FBD for ; Tue, 16 Sep 2003 19:48:06 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id MAA17388 for ; Wed, 17 Sep 2003 12:48:03 +1000 Date: Wed, 17 Sep 2003 12:46:41 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: smp@freebsd.org Message-ID: <20030917122543.O8168@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: atomicity of unlocked reads X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2003 02:48:07 -0000 What guarantees, if any, are there that an unlocked read provides a valid value (either the current value or a previous value)? Obviously there are no guarantees if the size of the object being read is different from the natural memory access size. I'm mainly interested in atomic reads of pointers in circular buffers. The read pointer is only written to by one thread and is locked by lock R. The write pointer is only written to by another thread and is locked by a different lock W. Each thread needs to read but not write the other thread's pointer but doesn't care if it sees a stale value (it will see an up to date value later), but does care if it sees a garbage value. It would be nice if each thread doesn't have to use the other thread's lock, especially when one of the threads is actually a fast interrupt handler so it can't use the other thread's lock unless it is a spinlock but wants to be a sleep lock. Sometimes even a garbage value from reading an object non-atomically might not matter. E.g., in sigpending() there seems to be no point in locking the read, since a snapshot that is inconsistent due to not locking during the read is little different from a snapshot that is inconsistent due to the object changing after it is read. Bruce