home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0052.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  4.5 KB
  1. From: Ronald Guilmette <uunet!ics.UCI.EDU!rfg>
  2.  
  3. In article <615@longway.TIC.COM> daveb@llama.rtech (David Brower) writes:
  4. >From: daveb@llama.rtech (David Brower)
  5. >
  6. >First, let me emphasise a point.  The Posix proposal is not requesting a
  7. >change in ANSI C.  It is saying that if a vendor is providing an C
  8. >environment that is supposed to work with shared variables, either in
  9. >shared memory or through the use of threads, than that environment needs
  10. >to meet some additional criteria  to conform to 1003.4
  11.  
  12. So far, that sounds reasonable.
  13.  
  14. > Among these is
  15. >that it not be necessary to put "volatile" in  front of declaration in
  16. >the universe for things to work right.
  17.  
  18. Here's where I diverge with 1003.4.
  19.  
  20. >
  21. >In article <601@longway.TIC.COM> Ronald Guilmette <rfg@ics.UCI.EDU> writes:
  22. >>From: Ronald Guilmette <rfg@ics.UCI.EDU>
  23. >>In article <5106@rtech.rtech.com> I write:
  24. >>>Posix 1003.4 is the "real time" extension to Posix.  It encompasses
  25. >>>shared memory and threads.  By including these features it introduces
  26. >>>some new restrictions on the compilation environment, the gist of
  27. >>>which are that almost everything needs to be treated as "partially
  28. >>>volatile" (my phrase).  The purpose of this note is to explore the
  29. >>>sense of the community tuned to ANSI C to see if this presents a
  30. >>>problem.  I *don't* have any problems with the proposed Posix
  31. >>>restrictions, and in fact consider them essential.  I do suspect that
  32. >>>some compiler writers may have some objections.  Some of the tricks
  33. >>>now used by "hyper-optimizing" compilers would be  illegal.
  34. >>>
  35. >>>The Draft 1003.4 Std. says in section 13.2:
  36. >. . .
  37. >
  38. >>Is it just me or does this strike anyone else as being pure gibberish?
  39. >>Are these "problems" defined somewhere?  Perhaps with examples of how
  40. >>these "problems" could crop up in some actual code?
  41. >
  42. >Yes, they are defined in the proposal; perhaps it is unfortunate that I
  43. >did not chose to type is in in it's entirely, including all the EQN
  44. >equations.  Sorry.  Many of Ron's rhetorical questions are answered
  45. >there.
  46.  
  47. I'd like to apologize to the entire net for foaming at the mouth in my
  48. previous posting on this subject.
  49.  
  50. The problem was that I was under the mistaken impression that the material
  51. which was posted *was* in fact the entire relevant section of the draft
  52. 1003.4 proposal.  I know better now, and I'm sorry.
  53.  
  54. I have since been in communication with one of the members of the 1003.4
  55. committee who has set me straight on a lot of things.  Now that I've
  56. had a chance to consider the *specifics* of what he is proposing,
  57. I have to say that I'm impressed that some members of the committe have
  58. in fact been doing their homework.
  59.  
  60. Still, even though the proposal which has been presented to me
  61. is quite technically detailed, and takes into account a large number of
  62. possible ramifications for various traditional and avant-guard architectures,
  63. I have to say that I'm still not fully in agreement with it.  I feel
  64. that the proposal I have seen has several significant shortcommings.
  65.  
  66. Still, I'm very much happier than I was before because *now* I at least
  67. have something quite detailed and concrete to pick at and to directly
  68. compare "volatile" with.
  69.  
  70. >The Posix committee apparently does not feel that it is reasonable to
  71. >require the programmer to write "volatile" on nearly everything to
  72. >insure correctness.
  73.  
  74. I don't yet know what the committe as a whole feels, but I can assure
  75. everyone that attaching "volatile" to *everything* is not necessary.
  76. Not by a long shot!  Is is saddening to hear such false generalizations
  77. made in public, and I have hopes that this is only the opinion of the
  78. poster, and not of 1003.4 as a whole.
  79.  
  80. >>>    The keyword causes inefficient code to be generated because any
  81. >>>    reference or store into a volatile variable must be immediately
  82. >>>    reflected in all other streams of execution, defeating any
  83. >>>    optimization or caching.
  84.  
  85. Some folks may have been under the impression that *all* things protected
  86. by a mutex would have to be volatile in order for volatile to be useful
  87. (and used) for multi-threaded programming.  This is *not* necessarily
  88. the case, and it may be possible to make only the mutex itself volatile.
  89. You kinda have to do that anyway.
  90.  
  91. Thus, this "inefficiency" of volatile, which some folks may be worried
  92. about may not be as bad as some fear.  In fact, it may actually approach
  93. zero on many architectures, and it may actually *be* zero on many others.
  94.  
  95.  
  96. // Ron Guilmette (rfg@ics.uci.edu)
  97. // C++ Entomologist
  98. // Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.
  99.  
  100.  
  101. Volume-Number: Volume 19, Number 52
  102.  
  103.