topic Re: Thread safety of a third party DLL in Intel® Moderncode for Parallel Architectures

Thread safety of a third party DLL

Shwetha_D_Intel — Tue, 06 Dec 2005 09:15:01 GMT

Interested in finding if your third party DLL is thread safe? See http://www.intel.com/support/performancetools/sb/CS-021533.htmfor details. New features will be highlighted on the product support pages regularly.

Re: Thread safety of a third party DLL

Henry_G_Intel — Thu, 08 Dec 2005 03:38:40 GMT

Hello,

This is a useful essay but I have a couple of minor comments. First, the DLL source codeshould show where the gPrimesFound variable is declared. Second, the statement "If Intel Thread Checker identifies issues...this indicates the dll is not threadsafe" is a little overstated. Consider the following function:

static int var;

void InitOnce ()

{

var = 0;

}

If the function InitOnce is added to the DLL and called from the OpenMP parallel region, Intel Thread Checker will report a write/write storage conflict on the variable var. This is a legitimate storage conflict but it is benign because all threads initialize var to the same value.

I oftensee one-time initializations when I analyze DLL's for threadsafety. I usually have the DLL source code so I know that this type of storage conflict can be ignored. Without source code, I have no way of knowing if the storage conflicts reported by Thread Checker are serious or benign so I have to err on the side of caution and not call the DLL with multiple threads.

Henry

Re: Thread safety of a third party DLL

jim_dempsey — Thu, 08 Dec 2005 05:38:19 GMT

Henry,

Consider

!$OMP PARALLEL

call InitOnce()

call DoSomethingThatModifiesVar()

!$OMP END PARALLEL

The above is a storage conflict. What you might want is

!$OMP PARALLEL

!$OMP MASTER

call InitOnce()

!$OMP END MASTER

!$OMP BARRIER

call DoSomethingThatModifiesVar()

!$OMP END PARALLEL

!$OMP PARALLEL

call InitOnce()

!$OMP BARRIER

call DoSomethingThatModifiesVar()

!$OMP END PARALLEL

The above is simplified and should be examined for usefulness

Jim Dempsey

Re: Thread safety of a third party DLL

jim_dempsey — Thu, 08 Dec 2005 05:43:56 GMT

I forgot to add...

If "var" is in a module that is part of the DLL then if two applications share the DLL the 2nd app could possibly reset "var" after the 1st app has modifyed it past 0.

If "var" is in the calling app's address space then there would be no conflict provided the InitVar was called once and before var is used.

Jim

Re: Thread safety of a third party DLL

Henry_G_Intel — Fri, 09 Dec 2005 06:11:12 GMT

Jim,

You're correct that initializing variables in a parallel region then modifying those variables can result in potentially serious storage conflicts. However, I was trying to illustrate that not all storage conflicts reported by Thread Checker are serious. One-time initializationsoften fall into the category of real yet benign conflicts.

Henry

Re: Thread safety of a third party DLL

ClayB — Fri, 23 Dec 2005 05:50:44 GMT

Henry -

Perhaps amore realistic example of a benign data contention would be using a shared variable to signal that a condition has been met, e.g., threads searching for the same item in a data set and two threads find the desired item within their assigned subset. If more than one thread determines that the condition has been met, they could both set the variable to the same value as the signal.

--clay