Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsp!gillies
From: gillies@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Volatile is Necessary
Message-ID: <77200028@uiucdcsp>
Date: 30 Mar 88 03:37:00 GMT
References: <8107@sol.ARPA>
Lines: 33
Nf-ID: #R:sol.ARPA:8107:uiucdcsp:77200028:000:1580
Nf-From: uiucdcsp.cs.uiuc.edu!gillies    Mar 29 21:37:00 1988


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.

We don't yet understand how to program multiprocessors well, or even
if shared-memory multiprocessing is the wave of the future.  Please
don't jump the gun by extending the C language too soon.  When
multiprocessing is solved, C will probably have been dead for many
years, and a multiprocessing language (perhaps a distant descendant)
will perform its function.

You can get what you want by adding a compiler-specific (#pragma type)
extension, with no loss of generality.  Do you think "volatile" will
make your programs portable to other multiprocessors????  Dream on!
Your arguments about shared-memory multiprocessors just are not
convincing.

THE ONLY reason to keep it in the language is if you can argue it's
important for uniprocessing.  I believe it might be important for
someone implementing monitors (a la MESA), if monitor locks could span
blocks, not just entire procedures.  But in this case, it's probably a
better idea to implement concurrency control directly in the language,
since this type of extension has been extensively researched.


I believe that you sincerely need this feature, but I also sincerely
believe that most people won't need it.  In top-quality standards
work, you learn to leave out the nonessentials.  Others can put them
in at their own discretion.

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {gillies@p.cs.uiuc.edu}