Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hpda!hpcupt1!hpisod2!dhepner
From: dhepner@hpisod2.HP.COM (Dan Hepner)
Newsgroups: comp.arch
Subject: Re: Coherent cache for Killer Micros
Message-ID: <13910003@hpisod2.HP.COM>
Date: 8 Dec 89 19:01:25 GMT
References: <13910002@hpisod2.HP.COM>
Organization: Hewlett Packard, Cupertino
Lines: 30

> >>Is a coherent cache system essential or just nice?  And why?
> 
> Depends if you want "consistent" results.

>--eugene miya

> I would rather like to write a paper entitled "On the Potential Uses
> of Invalid Data"...
> 
> Andy Glew aglew@uiuc.edu

I doubt either one of you would be slowed down all that much in
implementing a semaphore in an incoherent cache hardware environment.
You'll have to have the ability to initiate local cache flush from software.

Once you had the semaphore, you wouldn't have much trouble figuring
out how to consistently get the right answer.  This isn't an exotic
type question, although like Andy, I thought the asynchronous reference 
sounded interesting.

Eugene Brooks' extra software development answer sure makes sense, but 
once the semaphore is implemented, one might enquire as to just what the 
extra software development consists of.  I.e. the programming paradigm
wouldn't seem to be that different, and might be limited to combining
a cache flush with the release of the lock protecting concurrent 
access to the shared resource. Since the acquisition of such a lock
would seem likely even in a coherent design, why would software
development be fundamentally more difficult?

Dan Hepner