home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.19 / text0037.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  3.9 KB
  1. From: daveb@llama.rtech (David Brower)
  2.  
  3. First, let me emphasise a point.  The Posix proposal is not requesting a
  4. change in ANSI C.  It is saying that if a vendor is providing an C
  5. environment that is supposed to work with shared variables, either in
  6. shared memory or through the use of threads, than that environment needs
  7. to meet some additional criteria  to conform to 1003.4.  Among these is
  8. that it not be necessary to put "volatile" in  front of declaration in
  9. the universe for things to work right.
  10.  
  11. In article <601@longway.TIC.COM> Ronald Guilmette <rfg@ics.UCI.EDU> writes: 
  12. >From: Ronald Guilmette <rfg@ics.UCI.EDU>
  13. >In article <5106@rtech.rtech.com> I write: 
  14. >>Posix 1003.4 is the "real time" extension to Posix.  It encompasses 
  15. >>shared memory and threads.  By including these features it introduces 
  16. >>some new restrictions on the compilation environment, the gist of 
  17. >>which are that almost everything needs to be treated as "partially 
  18. >>volatile" (my phrase).  The purpose of this note is to explore the 
  19. >>sense of the community tuned to ANSI C to see if this presents a 
  20. >>problem.  I *don't* have any problems with the proposed Posix 
  21. >>restrictions, and in fact consider them essential.  I do suspect that 
  22. >>some compiler writers may have some objections.  Some of the tricks 
  23. >>now used by "hyper-optimizing" compilers would be  illegal. 
  24. >> 
  25. >>The Draft 1003.4 Std. says in section 13.2:
  26. . . .
  27.  
  28. >Is it just me or does this strike anyone else as being pure gibberish?
  29. >Are these "problems" defined somewhere?  Perhaps with examples of how
  30. >these "problems" could crop up in some actual code?
  31.  
  32. Yes, they are defined in the proposal; perhaps it is unfortunate that I
  33. did not chose to type is in in it's entirely, including all the EQN
  34. equations.  Sorry.  Many of Ron's rhetorical questions are answered
  35. there.
  36.  
  37. >>    ... further, using the volatile keyword to solve
  38. >>    memory coherence problems is both error prone and inefficient.
  39. >
  40. >Compared to what?  Do the people writing this stuff come from marketing
  41. >backgrounds?
  42.  
  43. I believe the answer is "compared to having to compiler gurantee that
  44. the sorts of things that would cause problems are not done."  I'm not in
  45. the Posix working group, so I can't speak for them.
  46.  
  47. >>    It is error prone because every variable accessed by more than one
  48. >>    stream of execution must be marked volatile, and if the mark is
  49. >>    forgotten the program might exhibit nondeterministic behavior.
  50. >
  51. >Yes.  If you write incorrect code, it will function incorrectly.  Is this
  52. >news to anyone?
  53.  
  54. The Posix committee apparently does not feel that it is reasonable to
  55. require making programmer write "volatile" on nearly everything to
  56. insure correctness.
  57.  
  58. >>    The keyword causes inefficient code to be generated because any
  59. >>    reference or store into a volatile variable must be immediately
  60. >>    reflected in all other streams of execution, defeating any
  61. >>    optimization or caching.
  62. >
  63.  
  64. >The issue of the effect on caching efficiency of the use of "volatile" is
  65. >potentially a real one, but *only* for multiprocessors (or uni-processors
  66. >with write-back caches), and *only* when certain types of cache coherency
  67. >schemes or certain types of cache coherency hardware is used on the
  68. >multiprocessors in question.  Even for such cases however, the effects
  69. >will probably be small for any realistic programs on good hardware.
  70.  
  71. Those are mighty big "onlys" if it's your machine at issue!
  72.  
  73. One major problem is linking in third party object modules to your
  74. shared memory or threading application, when you don't know if that
  75. object has had "volatile" sprinkled in enough places.  It would be
  76. better if the complier just did the right thing, and did not do
  77. optimizations that were inappropriate in a shared memory system.
  78.  
  79. I sure get the sense that this is a hot topic, though...
  80.  
  81. thanks,
  82. -dB
  83.  
  84. "Bo knows Elvis.  Bo IS Elvis."
  85. David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb daveb@rtech.com
  86.  
  87. Volume-Number: Volume 19, Number 45
  88.  
  89.