Path: utzoo!attcan!uunet!lll-winken!lll-crg.llnl.gov!brooks From: brooks@lll-crg.llnl.gov (Eugene D. Brooks III) Newsgroups: comp.lang.c Subject: Re: volatile (in comp.lang.c) Message-ID: <8055@lll-winken.llnl.gov> Date: 1 Jun 88 04:05:37 GMT References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <1988May23.003847.1114@utzoo.uucp> <21821@amdcad.AMD.COM> <1036@ima.ISC.COM> Sender: usenet@lll-winken.llnl.gov Reply-To: brooks@lll-crg.llnl.gov.UUCP (Eugene D. Brooks III) Organization: Lawrence Livermore National Laboratory Lines: 19 In article <1036@ima.ISC.COM> johnl@ima.UUCP (John R. Levine) writes: >Not so fast, there. In large multi-CPU systems, there is often a write-behind >cache and writes by one processor are not always visible to other processors >until you do some sort of cache-flush operation. (For example, on 370 >architecture machines the cache is only flushed on process switch, start I/O, >and a very slow flush no-op.) Bus based multiprocessors which do not have automatic cache coherency taken care of in the hardware are SICK as far as tightly coupled shared memory multiprocessing is concerned. If there is no automatic maintenance of cache coherence one has to have to kinds of loads and two kinds of stores to handle options of treatment of cached data. Multiprocessors without these needed features don't get used for tightly coupled multiprocessing, they are used in throughput mode. I stand by the need for volatile, I need volatile for several programs I run on shared memory multiprocessors if an "optimizing" compiler is to be used. This is not "educated guesswork" or "gut feelings" on my part. I have been programming shared memory multiprocessors for a half decade now and have been hosed over by optimizing compilers many times. Volatile is not a dead horse, expect several manufactures who deliver shared memory multiprocessors to have volatile with teeth in the future. It is fundamentally important!