From owner-freebsd-current Wed Mar 29 21:26:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 98D6337B764 for ; Wed, 29 Mar 2000 21:26:50 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id XAA40214; Wed, 29 Mar 2000 23:30:00 -0600 (CST) (envelope-from jlemon) Date: Wed, 29 Mar 2000 23:30:00 -0600 (CST) From: Jonathan Lemon Message-Id: <200003300530.XAA40214@prism.flugsvamp.com> To: bright@wintelcom.net, current@freebsd.org Subject: Re: Using packed structs to gain cheap SMP primatives X-Newsgroups: local.mail.freebsd-current In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >* 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. Each architecture will define what is atomic or not. Most modern architectures will provide atomic access to their native word size, provided it is aligned on a natural word boundary. On the PPro and upwards, 64 bit reads/writes to quadword aligned structures are atomic. it's just too bad that there is no direct 64-bit read insn (excluding FP). -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message