home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / msdos / programm / 9024 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.5 KB
  1. Xref: sparky comp.os.msdos.programmer:9024 comp.os.msdos.misc:5032
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!decwrl!access.usask.ca!ccu.umanitoba.ca!ciit85.ciit.nrc.ca!brandonu.ca!dueck
  3. Newsgroups: comp.os.msdos.programmer,comp.os.msdos.misc
  4. Subject: Re: Why ms-dos is non reentrant
  5. Message-ID: <1992Sep2.174517.2209@brandonu.ca>
  6. From: dueck@brandonu.ca
  7. Date: 2 Sep 92 17:45:17 CST
  8. References: <92245.122042A10742@TRMETU.BITNET>
  9. Organization: Brandon University, Brandon, Manitoba, Canada
  10. Lines: 62
  11.  
  12. In article <92245.122042A10742@TRMETU.BITNET>, Pinar Aydemir <A10742@TRMETU.BITNET> writes:
  13. > I almost hear everyday that msdos is non-reentrant.
  14. > It is non re-entrant so dont call a dos funcion from a Interrupt Service
  15. > Routine.
  16. > Since It is non reentrant, bla bla bla.
  17. > 
  18. > I looked at some books about OS, and the definition of reentrancy is
  19. > given as being unmodified (pure) code.So, what makes msdos non reentrant ?
  20. > Any information  is appreciated.
  21. > -Yasemin
  22.  
  23. That definition is not quite correct. Pure code just means that you don't
  24. modify code on the fly.
  25.  
  26. Reentrance requires the notion of a process: code + data. The code
  27. remains constant, but the data is different for each occurence of a process.
  28.  
  29. For example:
  30.    x dw 0
  31.  
  32. incrax:
  33.    mov x, ax
  34.    add x, 1
  35.    mov ax, x
  36.    ret
  37.  
  38. is not re-entrant, but
  39.  
  40. incrax:
  41.    push bp
  42.    mov  bp,sp
  43.    sub  sp, 2
  44.    mov  [bp-2], ax
  45.    add  [bp-2], 1
  46.    mov  ax, [bp-2]
  47.    mov    sp, bp
  48.    ret
  49.  
  50. is re-entrant. The difference? We have to consider that an interrupt handler
  51. can be invoked at any time (asynchronous), that it may call the incrax routine, and that
  52. at the time of the interrupt, the CPU was executiong somewhere in incrax
  53. (what I call a synchronous execution).
  54.  
  55. In the first example, an interrupt handler invoked asynchronously that 
  56. calls incrax will modify location x, thereby causing an incorrect
  57. result from the synchronous call to incrax,
  58.  
  59. An interrupt handler that calls incrax in the second example will not
  60. clobber location x, since the data areas used by the code is specific 
  61. to an instance of a thread of control. Thus the asynchronous execution
  62. cannot interfere with the synchronous execution.
  63.  
  64. In the case of DOS, the state of a system call is stored in fixed locations.
  65. A system call made from within an interrupt handler modifies the state
  66. represented by those locations. So when the interrupt completes, and
  67. the CPU return to the middle of an interrupted system call, the modified
  68. state is almost always incorrect.
  69.  
  70. I hope this helps.
  71.  
  72. Gery Dueck
  73. dueck@brandonu.ca
  74.