home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / wizards / 3618 < prev    next >
Encoding:
Text File  |  1992-08-14  |  2.0 KB  |  64 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!utcsri!torn!cunews!hobbit.gandalf.ca!mbeizer
  3. From: mbeizer@gandalf.ca (Martin Beizer)
  4. Subject: Lightweight Processes
  5. Message-ID: <1992Aug14.194356.8728@gandalf.ca>
  6. Keywords: lightweight processes, I/O
  7. Organization: Gandalf Data Ltd.
  8. Distribution: na
  9. Date: Fri, 14 Aug 1992 19:43:56 GMT
  10. Lines: 52
  11.  
  12. I would appreciate some help with a problem I'm having with lightweight
  13. processes on a Sparc. (The description below neglects detail for the sake
  14. of brevity.)
  15.  
  16. For simulation purposes I am porting a realtime kernel from 68K assembler
  17. to C on the Sun, using lightweight process calls to save state during
  18. context switches.
  19.  
  20. All "user" kernel tasks run at a single LWP priority level
  21. (although with different priorities in the context of the ported
  22. kernel).  This permits the translated algorithms to control which task
  23. runs, rather than leaving it up to the lightweight process scheduler.
  24.  
  25. Context switching in the scheduler looks like:
  26.  
  27.     if (next_task != current_task)
  28.     {
  29.         lwp_resume(next_task->lwp_tid);
  30.         lwp_suspend(last_task->lwp_tid);
  31.     }
  32.  
  33. In order to simulate a timer interrupt, a higher lwp priority task
  34. does essentially the following:
  35.  
  36.     while(1)
  37.     {
  38.         lwp_sleep(...)
  39.         if interrupts_ok
  40.             make_timer_task_ready_to_run
  41.     }
  42.  
  43. This runs the scheduler, and when the interrupt process goes
  44. back to sleep, causes a preemptive context switch to take place between
  45. lower LWP level user tasks. (Note that the interrupt process is never
  46. suspended.)
  47.  
  48. What happens is:
  49.  
  50. 1. If output is redirected into a disk file, it works fine.
  51.  
  52. 2. If output defaults to the terminal, it runs for awhile, until the
  53. higher priority interrupt process eventually is the only lightweight
  54. process left running.
  55.  
  56. It appears that I/O from the user proceses is distrubed by the
  57. preemptive scheduling ONLY WHEN I/O GOES TO THE TERMINAL.
  58.  
  59. I've experimented quite a bit.  Any ideas?
  60.  
  61. ----------------------------------------------------------------------
  62. Martin Beizer                  Gandalf Systems, Cherry Hill, NJ
  63. (609) 424-8700 X 5820            mbeizer@gandalf.ca, beizer@infotron.com
  64.