home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / programm / 3314 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  4.4 KB
  1. Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!Sirius.dfn.de!solaris.rz.tu-clausthal.de!urmel.informatik.rwth-aachen.de!messua!dak
  2. From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
  3. Newsgroups: comp.programming
  4. Subject: Re: reentrant code
  5. Date: 12 Dec 92 22:58:09 GMT
  6. Organization: Rechnerbetrieb Informatik - RWTH Aachen
  7. Lines: 74
  8. Distribution: world
  9. Message-ID: <dak.724201089@messua>
  10. References: <GARY.92Dec9104702@kuwait.gdfwc3> <1992Dec10.045716.12505@linus.mitre.org>
  11. NNTP-Posting-Host: messua.informatik.rwth-aachen.de
  12.  
  13. crawford@boole.mitre.org (Randy Crawford) writes:
  14.  
  15. >In article <GARY.92Dec9104702@kuwait.gdfwc3> gdfwc3!gary@uunet.uu.net writes:
  16. >>What are the requirements for code to be reentrant?  When can
  17. >>non-reentrant code hurt you?  Can someone recommend a good reference
  18. >>on this subject?
  19.  
  20. >Reentrant code must allow more than one task to concurrently execute the
  21. >same instructions in the same memory space.  If one thread of execution makes 
  22. >use of data which is the same data used by another thread, a possibility 
  23. >exists for one thread to overwrite the data written by the other.  This may 
  24. >not be apparent unless you remember that we are discussing programs which 
  25. >execute on pre-emptive multitasking operation systems.  When a task is 
  26.  
  27. >With non-reentrant code this isn't a problem.  All the code and data for each
  28. >task are in a separate process space from the other concurrent tasks, so tasks 
  29. >can't interfere with each other's data.  But reentrant code is meant to remain 
  30. >in memory after a context switch, allowing another task to reuse the memory 
  31. >and save the cost of swapping it out and then back in immediately.  The cost 
  32. >of this is that global variables within the reentrant code remain accessible 
  33. >to other concurrent tasks, and one task can overwrite the data written by a 
  34. >previous task before the first task had a chance to finish using the data.  
  35. >If I haven't beaten this to death yet, let me offer an example to help illus-
  36. >trate.
  37.  
  38. >I think that nearly all Unix system functions are reentrant, with the sole 
  39. >exceptions being a few C I/O functions like printf(), scanf(), etc.
  40.  
  41. >As far as good references on reentrancy, most OS texts discuss it (Deitel's
  42. >book and Peterson and Silberschatz's both do).  It's really an OS feature
  43. >and not part of programming language or compiler subject matter, so I wouldn't
  44. >look there for it.  Most OS-specific internals texts cover it as well (I think 
  45. >Bach's and Leffler's internals texts on SysV and BSD Unix do).  In Unix,
  46. >reentrancy is equivalent to setting what is called the `sticky bit' of a
  47. >program to keep it in memory if possible during context switches.  This is
  48. >commonly done for often used system routines and utilities (like ls or vi).
  49.  
  50. Most of that I do not agree with.
  51. The problems of reentrancy are a bit different from concurrency. Reentrancy
  52. may be a subject in system programming, because any subroutine an
  53. interrupt routine uses must work without disturbing an instance of
  54. the routine active before the interrupt. You can do that by saving all
  55. variables on some stack, restoring them afterward. Z80 Versions of Turbo
  56. Pascal did just that with local variables, because variables on the
  57. stack were not especially supported by the processor.
  58.  
  59. This technique is still there in interrupt routines saving all REGISTERS
  60. they might use.
  61.  
  62. Note that this reentrancy scheme works fine with interrupts as well as
  63. with recursions, with the latter NOT if you pass any variables of the
  64. recursion by reference.
  65.  
  66. It does not work with concurrency.
  67.  
  68. Reentrancy is also not merely a hidden OS-matter, at least not in Unix,
  69. because signal handlers may not use nonreentrant routines they might
  70. have interrupted.
  71.  
  72. And the sticky bit is an entirely different thing. In older versions of
  73. Unix, it told the system that execution of a program was likely to
  74. occur that often, that the system better keep a copy of the program
  75. in the swap area. Note that in this blissful old time, EVERY program
  76. was allocated in the swap area. So the fork() system call was pretty
  77. simple: it swapped the process, but did not invalidate the copy in core.
  78.  
  79. I cannot rule out all possibility that this copy might have had an
  80. already altered
  81. data area, and so the programs with sticky bit would have to be reentrant
  82. on systems not supporting shared text. But I believe in the sanity of
  83. the early Unix system designers.
  84.  
  85. By the way, concurrency or multithreadability is important for shared
  86. libraries.
  87.