[lug] Software/compiler issues w/dual CPU's

[Paul Hardiman]

If your apps aren't using threads, then ignore this.
Threads give your app more moveable parts. An smp can put more of those 
movable parts in motion concurrently.

If your apps use threads with g++, then you should switch from STL to 
STLPort (that has been built for thread safety).

You may experience some anomolies with concurrent creation of file 
descriptors in threaded apps on an smp that you might not experience on 
a single processor.  There are compile flags to mitigate this.

Hope this helps.

Sexton, George wrote:

>I have dealt with "TONS" of smp under linux and never encountered an
>application that would not run correctly because it was multi-cpu.
>
>Totally bogus point.
>
>Here is the real deal on SMP. If you write a multi-threaded application, and
>only test it on uni-processor you will probably not find bugs in your code.
>When the code is run on SMP machines, things MAY mysteriously break. Again,
>this only applies if you are writing multi-threaded code. This isn't because
>SMP causes problems, but because a multi-threaded application's dynamics
>change when run on an SMP machine.
>
>-----Original Message-----
>From: lug-admin at lug.boulder.co.us [mailto:lug-admin at lug.boulder.co.us]On
>Behalf Of Gary Hodges
>Sent: 25 June, 2002 8:58 AM
>To: lug at lug.boulder.co.us
>Subject: Re: [lug] Software/compiler issues w/dual CPU's
>
>
>Here is another comment from a colleague:
>
>: It's just that, one of the best reasons for going with
>: Linux on intel (or intel-ish) is easy access to binary
>: programs.  If a dual proc either can't run the majority
>: of binaries out there, or can run them but won't be
>: using the 2nd proc, then we might as well just get a
>: single.
>
>Is the above a valid point?
>
>GH
>
>
>Gary Hodges wrote:
>
>>...
>>
Regards,
Paul Hardiman
303-581-0006