Software application does not work on Centrino Duo (T2500)

[mayankraja]

Our customers have been using this particular application which is GUI based written in C++ to communicate with our tool on RS232. We have several thread in layer based architecture.
However since laptops came out with Centrino Duo processors, the same app doesn't work reliably.
If we diable one core, it works as it used to.

Do we have to do something special to make it work on Duo and Core Duo processors, like handle threads in some special way ?

[TimP]

If you are running Windows, you could set a Windows 98 compatibility tab on this application to restrict it to a single core. On linux, you might attempt this by e.g.

taskset -c1 yourapplication

The reason for inclusion of this effect in the Windows 98 compatibility is that such applications were often threaded on the assumption they would never run on a version of Windows supporting more than one cpu/core.

[mayankraja]

Thank you Tim18.

So, if I had to change it such that I do want it to run (take advantage of Centrino Duo) without retriction, what would I have to do ?

The code was written using MFC for the GUI application, and MS Visual C++ 6.0 for the DLLs, one of which is COM based.

It was compiled on XP platform without any changes to the code originally written for Win2K and 98. Let me know if you need more info.

Thank you for your help.

[jimdempseyatthecove]

It would be hard to say what changes would be required to your unseen code. However, I can offer some hints. These hints are not designed to instruct you as to properly code your application. Rather the hints are designed to help you "hack" in a quick fix.

In your application, on all the calls to your and system DLL's, and system calls in general, enclose the calls withi a CriticalSection. If that works, then you can experiment by removing each CriticalSection (one by one), until you find the one causing the problem, then skip that and continue removing CriticalSections.

The above may or may not work.

One of the reasons for failure on multi-threaded MP when multi-threaded SP works is operations that are atomic on one processor interfere in multi-processor configurations. You will have to check your code (visually) to find the problem areas. The hunt time for finding the problem is inversely proportional to the knowledge of the code that the hunter has. The usual suspects are queueing and summations. If you have queueing, linked lists, summation routines use the CriticalSection envelope technique above. Eventually you willfind thesensitive code.

Jim Dempsey

[mayankraja]

Hello Tim18,

So, i tried that. I also downloaded the Thread Checker evaluation copy. However, the behaviour is same. After sometime the RS232 communication dies. Which I am guessing, messages are lost between threads. The application doesn't crash or anything.

If I restart the communication (by re-selecting the same port which closes the read thread and port, and then opens the port and thread again), it works until next timeout.

Can I ask a basic question ? Does OS (XP in this case) decide to run threads/apps in same or different cores or there is the way you program (which I guess you would have to use latest MS Visual C++).

Thank you for your help.

[mayankraja]

Thanx Jim,

I will try that. I must say, I didn't write this code, so I guess it will be a big project for me. Thanx for the idea though.

Mayank.

[TimP]

If your application uses multiple threads, a multi-threaded OS will almost certainly try to spread them out among CPU resources, unless you take action to prevent that. As Jim mentioned, using critical sections might help you find out where it goes wrong. If the application was written for Windows 98, it seems doubtful that you could get a useful performance improvement from true multi-threading without a lot of work.

[jimdempseyatthecove]

You can programically specify a processor affinity. But this may not be your problem.

If the RS232 communication dies why would this cause a message to be lost between threads? (unless you mean each thread is running on a separate system and communicate via the RS232 port). Generally if the RS232 port is handled by one thread and the port "dies" then a message (packet) is not fully formulated and then sent to the "other" thread. i.e. messages are not lost between threads, they are lost on reception within one thread.

One of the potential problems with I/O on the newer processors is the newer processors are more aggressive at performing out-of-order reads and writes. You may need to insert memory fence instructions into your code to resolve temporal issues.

Jim Dempsey

[jimdempseyatthecove]

This may not be a big project for you. Choose a resolution method that converges on solution similar to binary search. And which are easiest to employ.

First, see you start the program to a "press any key to continue" or OK dialog box. Then use the Task Manager to force the app to run on one processor. You may need to do this before the additional threads are created.

Also, check your code to see if more than one thread is accessing the RS232 port. One of the threads may be disturbing a Flag (e.g. Data Ready). You may find you have one thread monitoring the port and another thread doing I/O.

An additional area to look at is your code assuming that the receiving system, once it begins reading a packet, will keep up with the transmission rate of the other system. i.e. a long system interrupt might cause a buffer overrun in the UART.

Jim Dempsey