From owner-freebsd-smp  Sun Feb  2 12:44:58 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA11102
          for smp-outgoing; Sun, 2 Feb 1997 12:44:58 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA11087
          for <freebsd-smp@freebsd.org>; Sun, 2 Feb 1997 12:44:54 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08516; Sun, 2 Feb 1997 13:42:33 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199702022042.NAA08516@phaeton.artisoft.com>
Subject: Re: SMP
To: davem@jenolan.rutgers.edu (David S. Miller)
Date: Sun, 2 Feb 1997 13:42:32 -0700 (MST)
Cc: terry@lambert.org, michaelh@cet.co.jp, netdev@roxanne.nuclecu.unam.mx,
        roque@di.fc.ul.pt, freebsd-smp@freebsd.org,
        smpdev@roxanne.nuclecu.unam.mx
In-Reply-To: <199702022002.PAA18631@jenolan.caipgeneral> from "David S. Miller" at Feb 2, 97 03:02:38 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Unless you hardware cache coherency support _really_ blows (ie. the
> architecture is essentially uninteresting) the most recent
> modification will claim ownership in that processors cache, it's
> called hardware cache coherency last time I checked.
> 
> For example if what you are describing is:
> 
> cpu1:
> 
> 	obj1 = foo_alloc();
> 	obj2 = foo_alloc();
> 
> 	dirty_up(obj1);
> 	dirty_up(obj2);
> 
> 	/* obj2 is no longer ours. */
> 	pass_reference(obj2, cpu2);
> 
> cpu2:
> 
> 	obj2 = get_reference_from(cpu1);
> 	dirty_up(obj2);
> 
> cpu2 will see cpu1's modifications to obj2 + whatever modifications it
> has made on top of cpu1's.  Unless you have really bad cache coherency
> hardware, this is guarenteed.

This is still not the problem.

The problem is, what happens to obj2 when obj1 is modified and the
cache line containing it is written has a piece of the old obj2,
then obj2 is discarded out of cache, and then later reloaded from
the memory copy which now contains corrupt data?  (NOTE: I said
*discarded* because CPU2 believes that the cache data is in memory
because it wrote its cache line before CPU1 wrote the stale obj2
data out).


> Only exception is with store buffers, on some implementations you can
> have available a memory model where either:
> 
> 	1) stores are executed out of order
> 	2) the store buffer is not snooped during cache transactions
> 
> In such a case, most of this ugliness is hidden around memory barrier
> instructions (either explicitly in the code, or inside of the locking
> primitive implementations themselves).
> 
> Or are you describing something completely different.

I'm talking case 2.

<------- cache line -------->
,---------------------------,
|  Obj1  |  Obj2  |         |
`---------------------------'

CPU1: (* = modify)
<------- cache line -------->
,---------------------------,
|********|  Obj2  |         | --> cache line containing O1, O2 is
`---------------------------'    written back to main memory

CPU2: (* = modify)
<------- cache line -------->
,---------------------------,
|  Obj1  |********|         | --> cache line containing O1, O2 is
`---------------------------'    written back to main memory

CPU1 cache line now contains invalid data for Obj2.
Main memory now contains stale data for Obj1.

Are you claiming that CPU2 would see the write of CPU1's cache line
in all cases, and invalidate it's own cache line?  Isn't there a
potential race?  I know it's unlikely, but it exists, right?

As far as I know, the write-through will not write *only* the
modified bytes, right?  Even if it wanted to, it would have to
at *lead take it to a longword boundry, right?


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.