Re: Safety and legality of optimizations

Vinod.Grover@Eng.Sun.COM (Vinod Grover) writes:


> Cliff Click <cliffc@crocus.hpl.hp.com> wrote:
> >Moving I/O across a potentially infinite loop is bad.
> >However, you _can_ move everything else across the loop, as long as you
> >preserve all data- & control- dependences. You can even move other
> >potentially infinite loops across.


> This is not quite true, especially in certain system applications
> where multiple threads or processes might be active. A typical case is
> when spinlocks/busy-waits are used for implementing critical sections.
> A critical section may contain non-I/O statements that manipulate a
> shared data structure, e.g. a bounded buffer. The lock-variable
> itself might be declared as volatile, but not necessarily the data
> structure being manipulated in the critical section:




I would claim shared data has volatile-like behavior. It can change
"unpredictably" behind the compiler's back, and thus has to be
flagged as volatile. This probably leads to unacceptable
performance. I think the problem lies with "volatile" - it's too
strong for threads (but just right for hardware interrupts). (I put
"unpredictably" in quotes because it's perfectly predictable, but C
has no way to tell the compiler the necessary information!).


Given the popularity of threads, it might make sense to champion a
"shared" keyword - something between volatile and nothing - but I
have no idea what! Of course, the parallel-language guys have been
at it awhile.


Can some kind netter post a summary of the popular paradigms for
shared structures and mutual exclusion _extensions_to_ languages_?
Or has the parallel-language community given up on C? :-)


Cliff
--
Cliff Click Compiler Research Scientist
Cambridge Research Office, Hewlett-Packard Laboratories
One Main Street, 10th Floor, Cambridge, MA 02142
(617) 225-4915 Work (617) 225-4930 Fax
cliffc@hpl.hp.com http://bellona.cs.rice.edu/MSCP/cliff.html
--

Return to the comp.compilers page.
Search the comp.compilers archives again.