benefits of QNX6 over QNX4

I was wondering if anyone would like to share their insights as to why
someone would want to use QNX6 over QNX4 for realtime programming on an x86
platform.

Thanks.

-Tom Worsnopp

Tom Worsnopp wrote:

I was wondering if anyone would like to share their insights as to why
someone would want to use QNX6 over QNX4 for realtime programming on an x86
platform.

  • Fully pre-emptable interrupt handler model (InterruptAttachEvent)
  • Priority inheritance is now default
  • SMP
  • Standard threading model (pthreads)

While QNX4 still posts better numbers on single cpu x86, it doesn’t
support SMP, so if your willing to throw extra hardware at a problem,
QNX6 can almost certainly handle more ambitious deadlines (on x86) than
QNX4 can.

There are a whole bunch more reasons that aren’t directly related to
real-time, but address general software engineering, and business concerns.

  • True DLL’s
  • Dramatically richer API.
  • At least the possibility of having a standard C++ compiler in the
    not-to-distant future.
  • New drivers (new driver support for QNX4 stops this year)
  • Bug fixes to the O/S (granted QNX4, doesn’t have many bugs left)

… and much more.

There are some very nice things about QNX6 like SMP, however I
think the shoe must be on the right foot. I think you would be
crazy to start new development under QNX4 unless there is some
known and unsolvable problem in QNX6 with your application.
The reason is threefold, Support, Support, Support. Just
my opinion.


Previously, Tom Worsnopp wrote in qdn.public.qnxrtp.newuser:

I was wondering if anyone would like to share their insights as to why
someone would want to use QNX6 over QNX4 for realtime programming on an x86
platform.

Thanks.

-Tom Worsnopp
\


Mitchell Schoenbrun --------- maschoen@pobox.com

For me and my company the question came down to support and our customers.
We develop a cross-platform C++, POSIX, TCP/IP vision server which runs on
an embedded VME PC (See what is embedded thread for fun) We started
development on a Windown machine and then moved over to QNX to get the real
time performance that we needed. While in development and after commitment
to the OS we discovered that the tool chain under QNX4 was not all that
nice. Plus the compiled went under, watcom. Watcom 10.6 does not contain
MMX Assembly, nor did it include the latest C++ language support.
Consenquently we ended up writting an additional System Software layer to
support this. Watcom 11.0, which only ever came out in beta for, ended up
having a memory error in malloc which ended that route. We currently have
to compile our MMX code in 11.0 and the rest of our app in 10.6. Then link
in 10.6 linker. Also our app relied heavily on threads. 99.9 percent of
the QNX OS calls are NOT thread safe, including malloc. This has severly
hampered our deliverables. There exists only an X11R5 implementation of the
X server is you need that component as well. Just some observations which
definitely pushed us to making the conversion to QNX6.

“Tom Worsnopp” <GreyCloak@northwestern.edu> wrote in message
news:a342gp$fse$1@inn.qnx.com

I was wondering if anyone would like to share their insights as to why
someone would want to use QNX6 over QNX4 for realtime programming on an
x86
platform.

Thanks.

-Tom Worsnopp