Q&A: Issue with 3rd party SDK and Threading

[Intel_Software_Netw1]

Here is a question received by Intel Software Network Support, as well as the response provided by our Application Engineers:

Q. We have developed an application based on an SDK provided by a company that manufactures a hardware-based MPEG capture solution. Our application is working with most Intel processors, but is not working with the Pentium 4 processor with Hyper-Threading Technology. It does work properly with the same configuration when HT is disabled. How can we resolve the issue?

A. From your description, it sounds as if the SDK provided by the company is not truly thread safe. Enabling HT allows the OS to schedule two threads of your process to run at the same time. When writing threaded applications, developers typically add synchronization objects, such as critical sections or mutexes, around shared data to permit only one thread at a time to access shared resources like memory or hardware. Another common coding practice is to use "events" to prevent a second thread from starting a task that should only occur after the first thread has completed a task (for example, the second thread wouldnt want to read from the hardware until the first thread has finished initializing the hardware). If such threading practices were not built into the SDK, it could cause a crash if one thread was accessing the resource at the same time as another, or if an operation was started in the wrong order. Technically this could crash on a non-HT-enabled system if the OS were to schedule the threads to run at just the right moment. So why does this only appear on HT-enabled systems? Timing. There may be a very small window of time in which the code is vulnerable to the thread conflicts, a window that is consistently being missed on non-HT-enabled platforms because things take a little longer. But on an HT-enabled system, multiple threads can be active at the same time, and the window of time where the code is at risk becomes reachable.

If you are running into this type of non-thread safe issue with your SDK, all is not lost: there are some things you can do to resolve the problem. First, ask your SDK vendor if they have a thread-safe version of their SDK; quite often vendors have single threaded and multi-threaded versions of their SDKs for performance reasons. If not, you can add your own thread synchronization objects around the SDK calls, by adding a mutex or critical sections around the suspected SDK calls to force your threads to only call one SDK call at a time. If the number of SDK calls is small, changing your architecture such that all the calls are made from the same thread might be an answer.

There is also the possibility that the SDK is thread safe, but the method in which your application uses it is not. For example, if your application were to pass the same memory buffer into SDK functions on two different threads, it is not the SDKs responsibility to protect the shared memory, but rather your application should protect that memory with a mutex, critical section, or event.

To find out where in your code there might be threading problems, we recommend the Intel Thread Checker for Windows*. It can analyze your code and tell you if resources are accessed by multiple threads and not properly protected. It can also identify potential deadlock situations. A free evaluation copy can be downloaded from: http://www.intel.com/software/products/threading/tcwin/index.htm

The following article from Intel Developer Services describes multithreading techniques:

Developing Platform Consistent Multithreaded Applications: Synchronization
http://www.intel.com/cd/ids/developer/asmo-na/eng/technologies/threading/hyperthreading/52510.htm

The following article from Microsoft* describes the various thread synchronization objects:

Multithreading: When to Use the Synchronization Classes
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_multithreading.3a_.when_to_use_the_synchronization_classes.asp

Please note that this link will take you to external web sites. Intel is not responsible for content or availability of these sites.

===
Lexi S.

IntelSoftware NetworkSupport

http://www.intel.com/software

Contact us

Intel is a registered trademark of Intel Corporation or its subsidiaries in the United States and other countries.

*Other names and brands may be claimed as the property of others.

Message Edited by intel.software.network.support on 12-07-2005 04:58 PM