Newsgroups: comp.realtime,comp.os.qnx,comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!news.sprintlink.net!sunserver.insinc.net!cuugnet!cyberdex!camz
From: camz@cyberdex.cuug.ab.ca (Martin Zimmerman)
Subject: Re: Real-time systems:  Windows-NT or QNX
References: <FriOct14102309EST1994@eric> <bbutlerCxo6Js.7L@netcom.com>
Organization: Cyberdex Systems
Date: Sat, 15 Oct 1994 20:49:20 GMT
X-Newsreader: TIN [version 1.2 PL2]
Message-ID: <CxqF6A.95A@cyberdex.cuug.ab.ca>
Lines: 56
Xref: glinda.oz.cs.cmu.edu comp.realtime:7157 comp.os.qnx:2212 comp.robotics:14397

Bryan Butler (bbutler@netcom.com) wrote:
> > I understand QNX use a strategy called pre-emptive scheduling where a
> I believe QNX also has threads. The two are not mutually exclusive.

QNX does not have threads, although some primitive support for them may get
added in the future.  With pre-premtive priority driven scheduling (there are
actually three scheduling algorithms which a process can select when it runs)

> eg if both threads try to modify a linked list and end up getting the list
> hopelessly screwed up. 

This is the big problem with threads, they can cause more problems than they
solve and they typically make the code much more difficult to debug.

> Drivers are always a pain to debug, no matter what type of system you
> are on, so be prepared.

QNX actually makes this process simple.  The OS is "constructed" of multiple
modules that all communicate via QNX's IPC.  QNX calls these resource
managers, and they run as normal processes, not in kernel space.  This allows
them to be started and stopped dynamically (without kernel rebuilds) and also
allows the developer to use normal debugging tools.  QNX even provides a few
examples of how to do this.

> I believe QNX supports X. The advantage here is that you can have 2 machines,
> one running process control, and the other acting as a display. The process
> control machine sends displays to the display controller, which performs
> the task of putting pixels on the screen. Thus, the process controller has
> a lot less work than if it had to do the display as well.

X has been in beta for several months now, and officially starts shipping on
Monday, October 15.

The QNX network actually "blends" each node (processor) on the network into
one large distributed OS.  The result is that resources available on one node
are available to all nodes.  So, a data-aquisition driver could be one a
dedicated node, and provide access to the real-time data via "devices" in the
/dev directory (say /dev/ad-ch1 ... /dev/ad-ch2) which other processes could
transparently access via the network.  You could even tie in other Unix (or
DOS, Windows, NT, etc.) boxes via TCP/IP and NFS to provide them with the same
transparent access to the realtime data.

> With that said, and with little real experience with QNX or NT, I would tend
> to trust QNX more. I wouldn't trust NT farther than I could throw it.

So, would I, I've been running QNX for 8 years now, on my personal machine,
and on computers throughout the world collecting realtime data on oil rigs.

Cheers,
Camz.

-- 
| Camz Enterprises - Martin Zimmerman | Now accepting contributions to  |
| QNX Programming & Consulting        | the comp.os.qnx FAQs.           |
| For additional information finger:  | Work is in progress on a QNX2   |
| zimmerm@cuug.ab.ca                  | and QNX4 FAQ, with QNX history. |
