osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (08/02/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c> mod.std.c Digest Thu, 1 Aug 85 Volume 9 : Issue 1 Today's Topics: Atomic operations in the C language - there's no hope free((void *) 0) unary +/- and regrouping ---------------------------------------------------------------------- Date: Thu, 1 Aug 85 02:30:28 edt From: "John R. Levine, P.O.Box 349, Cambridge MA 02238-0349 (617-494-1400)" <johnl@ima.UUCP> Subject: Atomic operations in the C language - there's no hope To: std-c@cbosgd A letter in V8 #17 suggests that it would be nice if the standard could guarantee that operations like a += 1 be atomic. Such an idea seems to me to be misguided. For one thing, many machines such as the IBM 360 series have no add-to-memory instructions, so they can't do it. Furthermore, different machines have different low level approaches to locking. Some, as noted, have regular instructions that atomically modify memory. Others have a conditional exchange instruction, an unconditional exchange instruction, or even in some cases a locking prefix that tells the cpu to execute the following instruction atomically. You can write all sorts of swell concurrent stuff in C, and the "volatile" keyword is an important feature for doing such stuff. But the right place for synchronization operators is in libraries. This needn't be impossibly slow - every Unix kernel is really a concurrent C program and some of them perform pretty well. Some of them even do so while running on many processors. This could be an interesting topic for further discussion but not, I think, in std-c. Feel free to send me mail. John Levine, ima!johnl Levine@YALE.ARPA ------------------------------ Date: Wed, 31 Jul 85 13:07:53 EDT From: ihnp4!seismo!elsie!ado Subject: free((void *) 0) To: hou2d!osd > D.10.3 Clarify that free() must not die if passed NULL since > {c,m,re}alloc can return such pointers. Many (most?) existing systems die if free is passed NULL. So let's mandate that free() MUST DIE if passed NULL. This will discourage folks from passing NULL to free, and will therefore encourage the development of more portable code. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX and Elsie are Digital Equipment and Borden trademarks ------------------------------ Date: Thu, 1 Aug 85 01:55:06 EDT From: ihnp4!seismo!elsie!ado Subject: unary +/- and regrouping To: hou2d!osd > > . . .If I understand alright, if I write > > (0-(a + (b + c)) > > then this may be (regroupedly) computed as > > (0-((a + b) + c)) > > whereas if I write > > -(a + (b + c)) > > such a regrouping is not allowed. . . > elsie!ado > . . .the most plausible interpretation. . .is that the > unary + or - only causes the parentheses that it immediately precedes to > be taken as inviolate -- this effect does not propagate inward. So the > compiler may not turn "z + +(a + (b + c))" into "(z + a) + (b + c)", but > may turn it into "z + +((a + b) + c)". > I use + in my example because it's not obvious just what the inhibition > of regrouping by unary minus *means*. . .I think the ultimate moral of > the story is the regrouping discussion in the C.3 intro needs rewording > for clarity. > Henry Spencer @ U of Toronto Zoology I agree with the suggestion about rewording; I'll try rewording C.3.3.3 below. First, though, as to what inhibition of regrouping by unary minus means-- perhaps it is that while a - (b + c) may be computed as (a - b) - c you can inhibit this by writing a + -(b + c) As for rewriting, I think changing Except that it inhibits regrouping, the expression +E is equivalent to (0+E). to read Except that it inhibits regrouping involving subexpressions of E, the expression +E is equivalent to (0+E). gets across my notion of what unary + is supposed to do, while Except that it inhibits regrouping of subexpressions of E with subexpressions outside of E, the expression +E is equivalent to (0+E). gets across Henry Spencer's notion. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX and Elsie are Digital Equipment and Borden trademarks ------------------------------ End of mod.std.c Digest - Thu, 1 Aug 85 21:11:47 EDT ****************************** USENET -> posting only through cbosgd!std-c. ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above.