Path: utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!sri-spam!ames!ucsd!rutgers!mtunx!whuts!homxb!genesis!hotlr!dkc
From: dkc@hotlr.ATT (Dave Cornutt)
Newsgroups: comp.lang.c
Subject: Re: Volatile is Necessary
Message-ID: <218@hotlr.ATT>
Date: 31 Mar 88 16:58:59 GMT
References: <8107@sol.ARPA> <77200028@uiucdcsp>
Reply-To: dkc@hotlr.UUCP (Dave Cornutt)
Organization: Not much, but I'm working on it
Lines: 54

In article <77200028@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes:
 > C is not a multiprocessor systems programming language.  I'm sorry for
 > you multiprocessor programmers.  My advice to you is to buy
 > hypercubes, write in assembly language, or develop your own language.

One of the reasons C exists is to replace assembly language in many
applications.

 > We don't yet understand how to program multiprocessors well, or even
 > if shared-memory multiprocessing is the wave of the future.

Shared memory is not confined to multiprocessors; it's useful on
uniprocessors too.  And it's not something in the far future;
it exists now, in both the SysV and BSD implementations of Unix
(although neither one is really spiffy), and in VMS, Amigados,
OS/2 I think, and probably a bunch more OS'es that I don't know
about.  Although the calls to set up the shared memory spaces on
these systems are not portable, the use of the resulting space
should be, since it's just a memory space.  C will lose out if
it fails to support these uses.

 > You can get what you want by adding a compiler-specific (#pragma type)
 > extension, with no loss of generality.

On the contrary, all generality is lost.  If it is made a pragma, vendors
will not be required to support it, and no specific syntax will be required
of those that do.

 > THE ONLY reason to keep it in the language is if you can argue it's
 > important for uniprocessing.

Here's a list of some of the things that you can't do properly on an
optimizing compiler without it:

signal catching
coroutines
device drivers
any kind of asynchronous event handler

These are common things right now.  What you're suggesting is that these
should not be considered conforming programs, because they use OS features
that are not portable to another OS.  Unfortunately, if you provide no
standardized way to do volatiles, then you not only can't port this code
to a different machine, you probably can't even port it to a different
conforming compiler ON THE SAME MACHINE!  Not only that, but you might
not even be able to port it to a different version of the SAME compiler!

An optimizing compiler without a volatile primitive cannot properly
compile a Unix kernel (or any other).

-- 
Dave Cornutt, AT&T Bell Labs (rm 4A406,x1088), Holmdel, NJ
UUCP:{ihnp4,allegra,cbosgd}!hotly!dkc
"The opinions expressed herein are not necessarily my employer's, not
necessarily mine, and probably not necessary"