From owner-freebsd-current Wed Mar 29 21:19:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D326F37B604; Wed, 29 Mar 2000 21:19:44 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e2U5iMS18883; Wed, 29 Mar 2000 21:44:22 -0800 (PST) Date: Wed, 29 Mar 2000 21:44:22 -0800 From: Alfred Perlstein To: Allen Pulsifer Cc: Mike Smith , Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: Using packed structs to gain cheap SMP primatives Message-ID: <20000329214422.X21029@fw.wintelcom.net> References: <20000329192526.U21029@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pulsifer@mediaone.net on Wed, Mar 29, 2000 at 11:36:05PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Allen Pulsifer [000329 21:05] wrote: > Here's another alternative for reading structures like time > that always change monotonically: read the values in > "MSB" to "LSB" order, then go back and check in reverse > order that nothing has changed. For example, to read a > structure containing hours, minutes, seconds: > > for (;;) > { h = timep->hour; > m = timep->minute; > s = timep->second; > if (m != timep->minute) continue; > if (h != timep->hour) continue; > break; > } > > The assumption is that from the instant you first read > timep->hour until the instant you double check its value, > it could not have wrapped all the way back around to its > previous value. Or to put it another way, if it has > succeeding in wrapping all the way around, having a > correct snapshot of the structure is the least of your > problems and the value you use is arbitary. > > This same method can be used to read the MSW and LSW of > any counter-like structure that is updated by an interrupt. > > Note this method will not work for a structure that can > both increment and decrement--it has to be only one or > the other. I'm aware of this, the problem is that tz may move in either direction. Hence my question about using sizes that are machine atomic for read/write. :) I've got several books on various systems here and I don't remeber any of them mentioning a problem with 32bit aligned updates being atomic. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message