peter@ficc.ferranti.com (Peter da Silva) (03/25/91)
C-language followups: please redirect to comp.lang.c Architecture followups: please redirect to comp.arch In article <40492@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: > The version 8 specification adds integer multiply and divide instructions. > In addition, a "Store Barrier" instruction was added that requires all stores > initiated before it to be completed before operation can continue. This is > designed to support future multiprocessor machines that allow memory > operations to occur out-of-order. One thing that occurred to me, reading this, is what impact this sort of instruction has on the use of "volatile" in C. 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. What's the answer? "#pragma really_volatile"? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
gwyn@smoke.brl.mil (Doug Gwyn) (03/27/91)
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.