Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!paperboy!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: New SPARC definition, and volatile
Message-ID: <15586@smoke.brl.mil>
Date: 26 Mar 91 22:11:48 GMT
References: <1991Mar21.185847.27784@elroy.jpl.nasa.gov> <40492@cup.portal.com> <CX8AUM7@xds13.ferranti.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 15

In article <CX8AUM7@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>If "volatile" implies the use of a "store barrier" instruction on writes,
>this would impact the performance of software that's using volatile to
>(for example) synchronise lightweight processes on a single CPU, but to
>not use it would break s/w that's using spinlocks for multiprocessor
>synchronisation.

I come from the school of thought that says that there is no simple way
to satisfy all concurrent programming needs by a simple hack to an
existing sequential language such as C.  In particular, "volatile" is
not necessarily the proper mechanism for this.  There is no C standard-
imposed requirement to tie generation of "store barrier" instructions
to accesses to volatile objects in such an implementation.  Indeed,
concurrency (other than asynchronous signal handlers) is entirely
outside the scope of the C standard, and deliberately so.