rock@cbnews.ATT.COM (Y. Rock Lee) (02/10/89)
Most of real time OS's support event on the application level. Inside UNIX KERNEL, one can also sleep on an event(address) and expect to be waken up later by someone else. But, on the user level a process can only sleep on TIME. Of course, it can be simulated on the user level to have a process sleep on an "event" and be waken up by a signal. I just wonder why UNIX doesn't want to give a user process the option to sleep on an event in addition to time? It doesn't seem to be very hard to me to add this feature to UNIX (forget the "real time" part, we don't want to change the scheduler). What is the philosophy behind the design of system call sleep()? Thanks in advance. Rock ------------------------------------- Y. Rock Lee (614) 860-4774 AT&T Bell Labs. Columbus, Ohio UUCP: att!cblpe!rock ARPANET/INTERNET: rock@cbnews.ATT.COM
chris@mimsy.UUCP (Chris Torek) (02/10/89)
In article <3921@cbnews.ATT.COM> rock@cbnews.ATT.COM (Y. Rock Lee) writes: >Inside UNIX KERNEL, one can also sleep on an event(address) >and expect to be waken up later by someone else. >But, on the user level a process can only sleep on TIME. >... What is the philosophy behind [this]? Not true (one can also await a signal with pause() or sigpause()), but the essential difference is that, while the kernel is multithreaded and thus needs a fancy scheduling mechanism, Unix processes are (normally) single-threaded so such a primitive is pointless. You can always write your own, by writing your own scheduler. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
john@anasaz.UUCP (John Moore) (02/13/89)
In article <15886@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: ]In article <3921@cbnews.ATT.COM> rock@cbnews.ATT.COM (Y. Rock Lee) writes: ]>Inside UNIX KERNEL, one can also sleep on an event(address) ]>and expect to be waken up later by someone else. ]>But, on the user level a process can only sleep on TIME. ]>... What is the philosophy behind [this]? ] ]Not true (one can also await a signal with pause() or sigpause()), ]but the essential difference is that, while the kernel is multithreaded ]and thus needs a fancy scheduling mechanism, Unix processes are ](normally) single-threaded so such a primitive is pointless. ] ]You can always write your own, by writing your own scheduler. I wish this were true! How does one write a SINGLE process that will wait for a character to appear on two different tty devices? How about waiting for a semaphore at the same time? I realize that all of this can be done by splitting the problem into a whole bunch of processes, but this is both costly of system resources and results in a more complex applications architecture. Unix is SERIOUSLY DEFICIENT in event handling. In our data communications systems that we do on Unix PC's, we wrote our own multi-event wait device driver to get around this. We'd much rather have good event management built into the kernel and standardized so that we can do things in a portable fashion. While I'm at it, I'd also like to mention that UNIX standard disk I/O is DEFICIENT. For serious transaction processing it would be nice to have kernel support for: (1) No-wait disk I/O: issue the request, get an event when I/O is done. (2) Good applications level notification and control for disk errors (a la GCOS-3 GEPR). (3) Prioritization of disk requests (4) Absolute, settable process priorities as an option. (Yeah, I know, this has nothing to do with disk I/O. But I thought I'd throw it in!) The best OLTP enhancements that I have seen are done by Pyramid - now when is AT&T going to wake up and include their sorts of enhancements in standard Unix so we can use them across a range of machines? -- John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john (602) 861-7607 (day or eve) The opinions expressed here are obviously not mine, so they must be someone else's. :-)
chris@mimsy.UUCP (Chris Torek) (02/13/89)
In article <1565@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: >... How does one write a SINGLE process that >will wait for a character to appear on two different tty devices? Use select(), of course. (Oh, stuck with SysV? Too bad :-) :-( ) >How about waiting for a semaphore at the same time? To a tune from _The_Wall_: We don't need no semaphores We don't need asynchrony No dark transactions in the system Hey! Kernel! Leave those disks alone! (4BSD does not have semaphores.) But it is true that most things are done synchronously. Also *simply*: which is what Unix is about. It was never intended to be a transaction processing system. If we had events and the like, we would *need* a fancy sleep mechanism like the one in the kernel. And it would be ugly. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
munir@hpfcmr.HP.COM (Munir Mallal) (02/16/89)
> Unix is SERIOUSLY DEFICIENT in event handling. In our data communications > systems that we do on Unix PC's, we wrote our own multi-event wait > device driver to get around this. We'd much rather have good > event management built into the kernel and standardized so that > we can do things in a portable fashion. This is why a number of vendors have enhanced Unix (tm) to add such features. Since you mention PC's, you should check out a company called VenturCom in Cambridge, Mass. They make a product called VENIX (for 286 and 386 machines). > While I'm at it, I'd also like to mention that UNIX standard disk > I/O is DEFICIENT. For serious transaction processing it would > be nice to have kernel support for: > (1) No-wait disk I/O: issue the request, get an event when I/O is > done. VENIX has this, and so do a number of other Unix's. > (2) Good applications level notification and control for disk > errors (a la GCOS-3 GEPR). Never tried GCOS! > (3) Prioritization of disk requests VENIX does this for 'Real Time' jobs. > (4) Absolute, settable process priorities as an option. (Yeah, > I know, this has nothing to do with disk I/O. But I thought > I'd throw it in!) Yup, this too. > The best OLTP enhancements that I have seen are done by Pyramid - > now when is AT&T going to wake up and include their sorts of enhancements > in standard Unix so we can use them across a range of machines? A number of enhancements added to VENIX help OLTP. > -- > John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john > (602) 861-7607 (day or eve) > The opinions expressed here are obviously not mine, so they must be > someone else's. :-) > ---------- Munir Mallal The opinions I post are believed to be mine.
stevens@hsi.UUCP (Richard Stevens) (02/17/89)
In article <7410001@hpfcmr.HP.COM>, munir@hpfcmr.HP.COM (Munir Mallal) writes: > > The best OLTP enhancements that I have seen are done by Pyramid - > > now when is AT&T going to wake up and include their sorts of enhancements > > in standard Unix so we can use them across a range of machines? Speaking of OLTP and Unix, I just received a blurb from AT&T UNIX Licensing for their "TUXEDO Transaction Processing System" which contains the "System/T" Teleprocessing monitor. Anyone know what this is ? The blurb didn't give any real information, and I've never seen any references to it (Usenix Proceedings, etc.). They claim its "currently running on selected vendor's platforms." Richard Stevens Health Systems International, New Haven, CT stevens@hsi.com ... { uunet | yale } ! hsi ! stevens