Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ames!mailrus!cwjcc!tut.cis.ohio-state.edu!osu-cis!att!cuuxb!dlm
From: dlm@cuuxb.ATT.COM (Dennis L. Mumaugh)
Newsgroups: comp.std.c
Subject: Re: volatile registers
Summary: setjmp and signals are marginal
Message-ID: <2349@cuuxb.ATT.COM>
Date: 7 Jan 89 01:11:14 GMT
References: <141@bms-at.UUCP> <275@twwells.uucp> <15166@mimsy.UUCP> <9236@smoke.BRL.MIL> <15171@mimsy.UUCP> <9316@ihlpb.ATT.COM> <2337@cuux <10720@rpp386.Dallas.TX.US>
Reply-To: dlm@cuuxb.UUCP (Dennis L. Mumaugh)
Organization: ATT Data Systems Group, Lisle, Ill.
Lines: 33

In article <10720@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US 
(The Beach Bum) writes:
>Shared memory has many applications which should be exploited.

As I alluded to in my article.   Actually shared memory has so many
pitfalls, even volatile isn't safe.   The WE32100 has a swapi
instruction that can be used for concurrency applications.  Guess
what?  Co-processors and caches do strange things then.   I think
volatile is a very dangerous construct and can and will bite the user
unless s/he is VERY carefull.
>
>A common usage is in interrupt [ software ] handlers where the
>signal catching routine sets a flag and returns.
>
I received a lot of mail about this use.   It is marginally
acceptable.   It is only necessary with aggressive optimizers
that do strength reductions on while loops and the user does
a 
	while( ! intflag) sleep(10);
type of construct.   Surely there are other better techniques.

I also saw comments that the constuct of a volatile register
was useful in setjmp/longjmp to preserve a register.  Perhaps
Doug Gwyn can comment whether this was accepted by ANSI or not.

Any other use of a volatile register is not meaningful unless one uses
lightweight/multithread processes sharing registers and doing
concurrent execution and that is sufficently mindboggling that I'd
program it in a decent language like NELIAC  [ half seriously now!].

-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm@arpa.att.com