home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / programm / 3356 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.4 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: avg@rodan.UU.NET (Vadim Antonov)
  3. Newsgroups: comp.programming
  4. Subject: Re: Semaphores, Swap, or Test_And_Set
  5. Date: 22 Dec 1992 18:20:53 -0500
  6. Organization: UUNET Technologies Inc, Falls Church, VA
  7. Lines: 42
  8. Message-ID: <1h87slINNshf@rodan.UU.NET>
  9. References: <1992Dec22.055727.8056@nestmoi.rain.com> <1h7htbINNdg6@usenet.INS.CWRU.Edu> <1992Dec22.192229.17569@pasteur.Berkeley.EDU>
  10. NNTP-Posting-Host: rodan.uu.net
  11.  
  12. In article <1992Dec22.192229.17569@pasteur.Berkeley.EDU> johnm@cory.Berkeley.EDU (John D. Mitchell) writes:
  13. >In article <1h7htbINNdg6@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
  14. >[...]
  15. >>I've been trying to figure out whether that LOCK prefix is necessary when
  16. >>sharing the code between several virtual 8086s running on one 386.   I have
  17. >>been unable to get a clear answer to this question -- is the LOCK prefix
  18. >>useful only for multiprocessors that take advantage of it, or does it also
  19. >>make the instruction noninterruptible?
  20. >
  21. >The LOCK prefix code of the i80x86 CPUs locks down the system bus.  On a
  22. >uniprocessor system it's only relevant if there is bus activity going on by
  23. >the processor's back (e.g., DMA (which makes the system essentially a form
  24. >of asymetrical multiprocessor :-)).
  25.  
  26. Never mind DMA. So far i saw no x86 machines (even real multiprocessors
  27. like Sequent i currently enjoy looking at through my office door)
  28. which have circuitry protecting DMA from colliding with locked memory
  29. locations.
  30.  
  31. LOCK prefix is useful only for multiprocessing, period.
  32. 386 isn't really good for multiprocessing (no per-page cacheability
  33. control), it was amended in 486 (but they added non-coherent internal
  34. cache to keep life funnier, sigh).
  35.  
  36. >>An answer to the effect of, "A 386 instruction is never interruptible" is
  37. >>OK, too -- I haven't been able to dig that sort of information out of the
  38. >>references I can find.
  39.  
  40. Wrong. Page faults DO interrupt 386 instructions. REP... instructions
  41. are interruptible by any interrupt source. 386 provides for
  42. restartability, not for non-interruptability of instructions.
  43.  
  44. >Note that some instructions can *NOT* be preceded by the LOCK
  45. >prefix.
  46.  
  47. I'd say *MOST* instructions cannot be preceded by the LOCK
  48. (486 manuals explicitly state that). See Intel's "Microprocessors
  49. vol I, 1992". Register<->memory XCGH should not be preceded by LOCK
  50. because it asserts LOCK signal automatically (for the sake of
  51. compatibility with 8086 -- who needs it?)
  52.  
  53. --vadim
  54.