followup to Igor's post in newuser

bridged with qdn.public.qnxrtp.advocacy
Robert Krten

Re: followup to Igor's post in newuser

Post by Robert Krten » Mon Jan 28, 2002 6:02 pm

Kris Warkentin <kewarken@qnx.com> wrote:
To say, "the apps are flakey, not the SMP" is a little disengineous since
most of the apps are not multi-threaded. If I've written an app that runs
multiple threads and it fails on an SMP system, then most likely I'm failing
to protect things properly. If a normal, run of the mill, single threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
"any single threaded app which works on a single CPU system should ALWAYS
work on a correctly implemented multi CPU system." I would invite you to
provide counter-examples if I'm wrong.
A single-threaded app that has an ISR will work fine on a single CPU box
but may fail dramatically on an SMP box. :-)

Cheers,
-RK
cheers,

Kris

"Bill Caroselli" <qtps@earthlink.net> wrote in message
news:a33sqe$btq$1@inn.qnx.com...
"Chris McKillop" <cdm@qnx.com> wrote in message
news:a30ilv$dea$1@nntp.qnx.com...
I understand both your and Igor's perspective that "a user" doesn't
care if it is QNX's SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver
that
doesn't run reliably on an SMP system should QNX take the blame? To
the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps and
services in general. The fact is that your phrelay issue would probably
happen on an non-SMP kernel as well, just harder to get the problem to
surface. It's a bug and I am sure you have reported it (right?).

If the problems are the apps and not the OS, that can only imply that the
apps aren't properly protecting data with semiphores. Is that the nature
of
the apps' probelms that have been found and fixed so far? If not, then it
seams like the apps are misbehaving because of flaky SMP features.

--
Bill Caroselli -- 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net




--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Chris McKillop

Re: followup to Igor's post in newuser

Post by Chris McKillop » Mon Jan 28, 2002 6:13 pm

Kris Warkentin <kewarken@qnx.com> wrote:
To say, "the apps are flakey, not the SMP" is a little disengineous since
most of the apps are not multi-threaded. If I've written an app that runs
multiple threads and it fails on an SMP system, then most likely I'm failing
to protect things properly. If a normal, run of the mill, single threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
"any single threaded app which works on a single CPU system should ALWAYS
work on a correctly implemented multi CPU system." I would invite you to
provide counter-examples if I'm wrong.
Although I am sure there are some cases (like rk pointed out), generally
this sort of statement is true. However, we do have many things that are
multi-threaded and this has tended to be where the problems existed. For
instance, phrelay is threaded, qnet is threaded and you can get some odd
effects when there is a client-server model as well (voyager).

chris


--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Kris Warkentin

Re: followup to Igor's post in newuser

Post by Kris Warkentin » Mon Jan 28, 2002 6:17 pm

Alright. I wasn't including ISR's in the list of ordinary, run of the mill,
application tasks but I suppose one needs to consider these sort of things
on QNX when all your drivers are running as ordinary (if privileged) apps.
Anyone else care to educate me further? I've often found that a strong
(even if erroneous) statement gets plenty of informative response. ;-)

Cheers,

Kris

"Robert Krten" <nospam91@parse.com> wrote in message
news:a343nf$gta$1@inn.qnx.com...
Kris Warkentin <kewarken@qnx.com> wrote:
To say, "the apps are flakey, not the SMP" is a little disengineous
since
most of the apps are not multi-threaded. If I've written an app that
runs
multiple threads and it fails on an SMP system, then most likely I'm
failing
to protect things properly. If a normal, run of the mill, single
threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
"any single threaded app which works on a single CPU system should
ALWAYS
work on a correctly implemented multi CPU system." I would invite you
to
provide counter-examples if I'm wrong.

A single-threaded app that has an ISR will work fine on a single CPU box
but may fail dramatically on an SMP box. :-)

Cheers,
-RK

cheers,

Kris

"Bill Caroselli" <qtps@earthlink.net> wrote in message
news:a33sqe$btq$1@inn.qnx.com...
"Chris McKillop" <cdm@qnx.com> wrote in message
news:a30ilv$dea$1@nntp.qnx.com...
I understand both your and Igor's perspective that "a user" doesn't
care if it is QNX's SMP or an app that sucks on SMP. However, how
far
do you take such a notion? If someone external to QNX does a driver
that
doesn't run reliably on an SMP system should QNX take the blame? To
the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps
and
services in general. The fact is that your phrelay issue would
probably
happen on an non-SMP kernel as well, just harder to get the problem
to
surface. It's a bug and I am sure you have reported it (right?).

If the problems are the apps and not the OS, that can only imply that
the
apps aren't properly protecting data with semiphores. Is that the
nature
of
the apps' probelms that have been found and fixed so far? If not, then
it
seams like the apps are misbehaving because of flaky SMP features.

--
Bill Caroselli -- 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net







--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Rennie Allen

Re: followup to Igor's post in newuser - SMP Flaky?

Post by Rennie Allen » Mon Jan 28, 2002 6:20 pm

Mario Charest wrote:

Do I sound like i'm trying to minimize my statement. You bet I do.......
Glad to hear this, since this whole SMP thread started when I made (what
I thought was a very non-controversial statement) that one could count
on SMP support for the next 10 years or so (after that it will probably
be quantum computer support that everyone will be clamoring for :-)

Wayne Fisher

Re: followup to Igor's post in newuser

Post by Wayne Fisher » Mon Jan 28, 2002 9:09 pm

"Chris McKillop" <cdm@qnx.com> wrote in message
news:a30j7f$dea$2@nntp.qnx.com...
[snip]
And, just for the record, I was a QNX customer/user/developer for nearly
5 years before I came to work for QNX. From autonomous robotic vehicles
to
embedded sensor systems for mining research to high-speed vision systems
for industrial control and manufacturing (hi wayne!).

chris
D'Oh! You caught me lurching, Chris.

Wayne

Jutta Steinhoff

Re: followup to Igor's post in newuser - SMP Flaky?

Post by Jutta Steinhoff » Mon Jan 28, 2002 11:05 pm

Camz,
nice to hear these statements from you ...
and just remembering the legendary SMP thread!

Igor and Armin will read twice...

Cheers, Jutta

Martin Zimmerman wrote:
Previously, Bill Caroselli wrote in qdn.public.qnxrtp.advocacy:
SMP has been flaky, and I wouldn't be surprise if it gets dropped.

QSSL, can you confirm or (hopfully) deny any thoughts whatsoever of dropping
SMP?

While I can't speak for QSSL, I can say with high confidence that SMP
isn't going to go away. One of the big new markets that QNX is playing
in is Telecom, and in that market embedded does not mean small. In many
cases it means SMP, and not just dual CPU SMP, but more often quad CPU
and 8 CPU SMP systems. Those high-end routers and intelligent internet
devices eat SMP for breakfast.

...and that in nushell makes SMP table stakes. It's not going anywhere.

Cheers,
Camz.

ps. SMP is also quite effective at finding all the threading issues/bugs in
your code SO much faster than on a single CPU machine.

--
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting

Mitchell Schoenbrun

Re: followup to Igor's post in newuser

Post by Mitchell Schoenbrun » Tue Jan 29, 2002 12:29 am

Kris,

With the provision that any program with an interrupt handler
is, at least potentially, multi-threaded.



Previously, Kris Warkentin wrote in qdn.public.qnxrtp.advocacy:
To say, "the apps are flakey, not the SMP" is a little disengineous since
most of the apps are not multi-threaded. If I've written an app that runs
multiple threads and it fails on an SMP system, then most likely I'm failing
to protect things properly. If a normal, run of the mill, single threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
"any single threaded app which works on a single CPU system should ALWAYS
work on a correctly implemented multi CPU system." I would invite you to
provide counter-examples if I'm wrong.

cheers,

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

Mitchell Schoenbrun

Re: followup to Igor's post in newuser

Post by Mitchell Schoenbrun » Tue Jan 29, 2002 12:32 am

Previously, Kris Warkentin wrote in qdn.public.qnxrtp.advocacy:
Alright. I wasn't including ISR's in the list of ordinary, run of the mill,
application tasks but I suppose one needs to consider these sort of things
on QNX when all your drivers are running as ordinary (if privileged) apps.
Anyone else care to educate me further? I've often found that a strong
(even if erroneous) statement gets plenty of informative response. ;-)
Well it is always possible that a library function might hide some thread
creation, but in this case, like the case of QNX supplied utilities,
SMP should work, or the mud is in QNX's eye.

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

Chris McKillop

Re: followup to Igor's post in newuser

Post by Chris McKillop » Tue Jan 29, 2002 5:20 pm

And, just for the record, I was a QNX customer/user/developer for nearly
5 years before I came to work for QNX. From autonomous robotic vehicles
to
embedded sensor systems for mining research to high-speed vision systems
for industrial control and manufacturing (hi wayne!).

chris

D'Oh! You caught me lurching, Chris.
hahaha, knew I would! ;)

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Pete Patterson

Re: followup to Igor's post in newuser

Post by Pete Patterson » Thu May 02, 2002 11:35 am

D'Oh! You caught me lurching, Chris.

Wayne
Quit drawing attention to the lurkers!!

Post Reply

Return to “qdn.public.qnxrtp.advocacy”