Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!bellcore!decvax!decwrl!spar!kissell
From: kissell@spar.UUCP (Kevin Kissell)
Newsgroups: net.micro
Subject: Re: What Unix needs is ...
Message-ID: <229@spar.UUCP>
Date: Fri, 3-May-85 14:04:10 EDT
Article-I.D.: spar.229
Posted: Fri May  3 14:04:10 1985
Date-Received: Mon, 6-May-85 00:15:21 EDT
References: <381@wdl1.UUCP> <> <154@soph.UUCP>
Organization: Schlumberger Palo Alto Research, CA
Lines: 24

> The problem is simple:  suppose two processes, communicating with
> shared memory, need to access locations N and N+X?  If they are
> running on the two different CPUs, there is no way to determine whether
> mutual exclusion has been achieved on the chunk of memory with location
> N unless you know the cache chunk size.
>
> 	Dave Brownell

Per-CPU caches do present coherence problems in multiprocessor configurations.
There are two reasonably well-known methods for dealing with them.  The first
is to create an address subspace from which data may not be cached, and use
this space for modifiable shared structures.  The second method is to give
all caches in the system the means to monitor the activity of other caches,
so that a modification of (shared) data in a cache will cause the invalidation
of the corresponding data in all other caches.  Neither method requires any
knowledge of the size of cache lines between processors.  By cacheing only 
instructions, the 68020 avoids the problem altogether, unless you want to worry
about shared, self-modifying code ;-).

Kevin D. Kissell
Fairchild Advanced Processor Development
uucp: {ihnp4 decvax}!decwrl!\
                             >spar!kissell
    {ucbvax sdcrdcf}!hplabs!/