From: kweber@Snake.mcs.kent.edu (Ken Weber)
Newsgroups: comp.parallel
Subject: Re: Atomic read/writes to memory in SMMs--SUMMARY
Date: 15 Apr 92 16:13:03 GMT
Organization: Kent State University
Originator: kweber@Snake.mcs.kent.edu

Thanks to all who responded to my question about reading from/writing
to shared memory.  This is an edited compilation of the responses
giving specific examples of machines which DO NOT have atomic 32-bit
read/write access to shared memory.

There was some confusion about my original question (probably because
it was not clear!).  Let me repeat the clarification I posted last
week:

    What I am referring to is the ability for a 32-bit value to be
    either written or read atomically from a memory location.  I
    could envision the situation where a read/write may work with
    only 16 bits of a value at a time.  This could lead to the
    following situation:

    Process 1 writes to low 16 bits of location A 
    Process 2 writes to low 16 bits of location A 
    Process 2 writes to high 16 bits of location A 
    Process 1 writes to high 16 bits of location A 

    Thus in location A we have the low bits from process 2 and the
    high bits from process 1.

What follows are the pertinent responses, condensed somewhat to make
easier reading.  If this sparks any further comments I would be
interested in them.

Ken Weber

1.  ... most caches are implemeted by external chip sets in the
higher end machines.

For mips boxes the norm is to do IO to memory in cache line sizes.

2.  ...In any case,
having just scanned the "Inside the TC2000 manual", I can tell you
that reads and writes on bytes, halfwords, and words (32bit) are all
atomic on this machine.  I unfortunately do not have the GP1000
manual set with me but I would guess these operations are atomic on
that machine as well.  To find out explicitly, you could call BBN
Advanced Computers.

3.  ... I believe that some chips with 32 bit registers and 16 bit
busses do preserve atomicity (80386 SX for one?) for 32 bit
load/stores.

4.  On the first and second generations of the BBN Butterfly, atomic
read-modify-write operations such as fetch-and-add and
fetch-and-store operate on only 16 bits at a time. This proved to be
very inconvenient since virtual addresses on the machine are 24 bits
(68000-based architecture): one couldn't manipulate pointers with
these primitives atomically.  However, the machine does support a
block transfer operation can be used to atomically read or write
blocks of up to 256 bytes.

5.  This exact problem could occur in the Alliant FX/8.  An FX/8
could contain up to 8 CE processors and up to 12 IP processors.  The
CE's could do atomic reads and writes of 64 bits at a time.  The IP's
were powered by Motorola 68012's and could only do atomic reads and
writes of 16 bits.

User code rarely had a problem with this.  Most multiprocessing with
shared memory by user code was done only on CE's.  However, the
CONCENTRIX kernel had nearly all of its data structures in memory
shared by all the CE's and IP's.  The situation you describe above
not only could occur, it DID occur.  (It caused some very strange
bugs).

6.  SPARC arch has a 32 bit atomic load. ie every operation is
converted to a 32 bit size. If a byte is written, the upper 3 words
will be zero'ed etc.  M88K is also similar as I recall.
Newsgroups: comp.parallel