Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!umd5!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.lang.c Subject: Re: volatile (in comp.lang.c) Summary: sig_atomic_t Message-ID: <329@proxftl.UUCP> Date: 16 Jun 88 17:55:38 GMT References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <4922@ihlpf.ATT.COM> Organization: Proximity Technology, Ft. Lauderdale Lines: 19 In article <4922@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes: > |Fortunately this is sufficient when the programmer understands what he is > |programming, and chooses data types etc which will ensure atomicity, if that > |is what he is trying to achieve. > > C itself does not guarantee that access to any particular data type, > including char, is atomic. My question is: is there *any* use for 'volatile' > which does not require 'atomicity' at some level? If not, then 'volatile' > doesn't really fix any of the problems we have without it. The standard solves this problem, almost: 4.7: "The type defined [in header] is sig_atomic_t which is the integral type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts." Of course, this does not really deal with multiprocessor systems unless one stretches the definition of asynchronous interrupts to include asynchronous memory use, a long stretch indeed.