Date: Thu, 6 Apr 2000 06:49:23 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Alfred Perlstein <bright@wintelcom.net> Cc: current@FreeBSD.ORG Subject: Re: Using packed structs to gain cheap SMP primatives Message-ID: <00Apr6.064925est.115226@border.alcanet.com.au> In-Reply-To: <20000329221042.Y21029@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Mar 31, 2000 at 12:50:51AM %2B1000 References: <local.mail.freebsd-current/20000329192526.U21029@fw.wintelcom.net> <local.mail.freebsd-current/NBBBJNDFEKPEHPFCLNLHMEIJGHAA.pulsifer@mediaone.net> <local.mail.freebsd-current/20000329214422.X21029@fw.wintelcom.net> <200003300530.XAA40214@prism.flugsvamp.com> <20000329221042.Y21029@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 31, 2000 at 12:50:51AM +1000, Alfred Perlstein wrote:
>What I'm calling for is a vote if we'll rely on this type of behavior
>(32 bit stores being atomic with respect to readers) or not, or
>perhaps to rely on it but mark it somehow so people can "fix it"
>if the need arises later by using other locking primatives on what
>should be atomic updates.
I can't imagine any implementation with an N-bit bus where N-bit
aligned transfers were not atomic WRT other N-bit aligned transfers.
It may not be (and probably isn't) guaranteed for non-aligned
transfers, or for smaller bus sizes (anyone for a 386SX SMP box?).
Larger bus sizes are also problematical - they may require some form
of RMW sequence to update an object smaller than the bus. If more
than one writer is allowed to the bus-word containing the object, some
form of locking will probably be necessary anyway (the Alpha, and
presumably the IA64, special-case 32-bit R/W, but future architectures
may not).
Since we started talking about packed structs, it's worth remembering
that struct { short foo[2];} will only require short alignment and
therefore may not wind up with 32-bit alignment.
IMHO, we can't rely on 32-bit stores being atomic in the future, but
there will be some size where this will be true. This suggests that
the objects or object accesses should be marked somehow. (Of course,
since this size will be the `most efficient' size for that
architecture, it should be C's `int' type).
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Apr6.064925est.115226>