🚀 go-pugleaf

In article <1992Dec11.131542.9190@jarvis.csri.toronto.edu>,
hsandhu@sys.toronto.edu (Harjinder S Sandhu) writes:

|>chased@rbbb.Eng.Sun.COM (David Chase) writes:
|>>I've had this nagging suspicion for about a year that people building
|>>MP's were working awfully hard to maintain coherency where it just
|>>didn't matter.  Given that most of the programming languages tell you
|>>to lock your data if it is shared, the "we're guarding against this"
|>>examples always looked like buggy programs to me.  People have been
|>>working on this at Rice, I know, and at least one other place that I
|>>cannot recall right now.
|> 
|>  Along the same lines, we have implemented and experimented with
|>a software coherence strategy based on the notion that applications
|>explicitly lock/unlock shared data. It requires no hardware or 
|>compiler support, but does rely on the programmer to program "correctly". 
|>This is described in a paper that will be appearing in the 1993 ACM SigPlan
|>Symposium on Principles and Practice of Parallel Programming in May:
|>"The Shared Regions Approach to Software Cache Coherence on
|>Multiprocessors". It will also be made available via ftp soon; send mail 
|>if you are interested.

IBM's approach should be able to streach scalability. hardware cache coherency
requires a lot of work. A lot of the time the software does not need the
coherency, ergo it makes sense to use software to solve the problem.

I disagree with the statement about putting the work onto the programmer though.
This work should go into the compiler. this may require a shift away from
traditional FORTRAN inspired approaches.

The IBM approach would be interesting for CSP. There data is explicitly locked
and unlocked. The model also sits very nicely with oops since it *is* a message
passing paradigm,

--

Phill Hallam-Baker