|Re: Optimizing Across && And || email@example.com (1995-02-23)|
|Re: Safety and legality of optimizations firstname.lastname@example.org (1995-03-21)|
|Re: Safety and legality of optimizations Vinod.Grover@Eng.Sun.COM (1995-03-28)|
|Re: Safety and legality of optimizations email@example.com (1995-04-03)|
|Re: Safety and legality of optimizations firstname.lastname@example.org (Charles Fiterman) (1995-04-15)|
|Re: Safety and legality of optimizations Dave@OCCL-CAM.DEMON.CO.UK (Dave Lloyd) (1995-04-18)|
|Re: Safety and legality of optimizations email@example.com (1995-04-17)|
|Re: Safety and legality of optimizations firstname.lastname@example.org (1995-04-21)|
|Re: Safety and legality of optimizations email@example.com (1995-04-26)|
|From:||firstname.lastname@example.org (Cliff Click)|
|Organization:||Hewlett-Packard Laboratories, Cambridge Research Office|
|Date:||Mon, 3 Apr 1995 15:08:38 GMT|
Vinod.Grover@Eng.Sun.COM (Vinod Grover) writes:
> Cliff Click <email@example.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 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
Return to the
Search the comp.compilers archives again.