strange behavior of C function strcmp() With OPENMP

[digimat]

Dear OPENMP users,
I observe a very strange behavior with c function strcmp() while using with openMP. I hope you one of you can help me to understand the reason.
Here is my code
int func(char * name)
{
static vector<char *> sNames;
bool newname = false;
char *mNameToStore=new char[256];
strcpy(mNameToStore,name);

if (sNames.size()==0) newname = true;
for (i=0;i<(int)sNames.size();i++)
{
if(strcmp(sNames.at(i),matName)==0)
{
position=i;
return i;
}
if(i==(int)(sNames.size()-1))
{
newname = true;
}
}
if (newname) sNames.push_back(mNameToStore);
return sNames.size();
}

When I try to execute my program with two threads, the block written in bold ( if(strcmp(sNames.at(i),matName)==0)) does not seem to work as expected, But everything goes fine while running with a single thread. This code has been existing since long under windows and linux platform. I am shifting the code to SMP version and I get blocked by this weird stuff !!! The code crashes because the index is passed incorrectly. I used TotalView to debug my code, where I observed this. Any help is welcome. I am using PGI compiler.
Thank you,

[ejd]

I am a little confused by your example code. You are passing in "name" to "func", but you are comparing "matName" (which isn't defined) in the strcmp. Also, where exactly is the parallel region? Is this function being called from a parallel region? If so, then where is "i" (the for loop iteration var) declared? If it is global, then it is shared and could be a problem. Another problem may be that the "push_back" isn't thread safe. More information please.

[digimat]

Hello ejd,
Thank you for the reply. I have made mistakes in my previous code. I am really sorry for that. I just try to project a situation that I have in my code. Here is the corrected code.
int func(char * name)
{
int i;
static vector<char *> sNames;
bool newname = false;
char *mNameToStore=new char[256];
strcpy(mNameToStore,name);

if (sNames.size()==0) newname = true;
for ( i=0;i<(int)sNames.size();i++)
{
if(strcmp(sNames.at(i),name)==0)
{
return i;
}
if(i==(int)(sNames.size()-1))
{
newname = true;
}
}
if (newname) sNames.push_back(mNameToStore);
return sNames.size();
}
This function is called in a parallel region. As the strcmp() fails the return index i is not correct. Which later leads to problem.
Thank you,

[ejd]

Now comes the fun part. Say that you have a parallel region with 2 threads calling this routine and that it hasn't been called before (so the Snames vector is not initialized yet). Both calls can see the sNames.size() call return zero and set newname to true. The for loop will then go from zero to zero and not be done. Variable "newname" is true, so both will try and do sNames.push_back (which might not work correctly because the C++ library would have to do internal locking on the structure) and you will see a return of the size of the sNames vector. The strcmp didn't fail - it was never executed.

Note my comment on the C++ library. Many libraries are "thread safe" meaning that the library can be called from multiple threads. However, it does not mean that the data structures like vector are really thread safe. This is one of the problems with terminology that isn't standardized. You most likely will have to protect calls like sName.push_back with a critical.

By now you should be able to see your problem. As you are searching the list, another thread may be adding to it. Your algorithm needs to be adjusted to take this into account.

[digimat]

Hello Ejd,
Thank you for pointing me existing problem. Sorry but sone thing is not clear. The code does not crash at the first step. It continues N step in my case N=8, at step 8 it crashes. I am using totalviewer to debug the code and what I observed is at step 8 strcmp() does not work. so the bool newname is turned on. which increases the counter value. I am using this counter to access other array which contains details for this specific name. It where the code crashes.
One more thing. Where can I find these kind of specific details? Do you recommend any documents or book?
I thank you again for pointing me the possible error.

[ejd]

My best guess without having the same setup as you do, would be that one thread may be trying to push_back to the list at the same time you are trying to look at aNames.at(i) in the strcmp. Like I said, a lot of the C++ libraries are thread safe, but the structures they use are not. So if the push_back increments the size prior to updating the list and another thread tries to look at the list (sNames.at(i)) at that point, I could see that strcmp might fail. The problem is, even when you use a debugger, you have to be careful as to how it stops and steps through code. You need to stop and look at both values of the strcmp without stepping any of the threads any further - and even then it might not show you exactly what is happening. Sorry - it is my best guess because I don't know how you are running this code. If you tell me the compiler and hardware you are running on, then maybe I can give you a better answer.

As for books or documents - I don't know what "level" you are looking for. What do you mean by "these kind of specific details"?

[digimat]

Hello Ejd,
I thank you again for the time and the explanation.
I am using PGI compiler. Running the job on AMD opteron under Redhat.
I am looking for a book that talks about the details of OPENMP behavior with STL standar containers(beginners to average level) . How a static variables, variables with extern keyword are handled in the OPENMP environment.
"these kind of specific details" - I mean to say that I was not aware that push_back of vector is not thread safe.
Thank you,

[ejd]

Unfortunately I don't have the setup you have available to me. Maybe someone else reading this forum can help you more.

As for books, there are several out about parallel programing that have mentions of OpenMP. However, as far as I know, there are only three out that go into OpenMP in any real detail. Chandra's book has been around for quite a while and only covers OpenMP version 1. It is interesting from a historical perspective, in that it gives some of the reasoning behind various decisions that were made originally. Mattson's book is not OpenMP specific, but Tim has been very active with OpenMP for years and he uses OpenMP throughout his book. The newest book is by Chapman, Jost, and Ruud (covering through OpenMP V2.5) and I have not yet had a chance to look at it. I know all three of the authors and they have all been very active with OpenMP for many years. Unfortunately, all I can really suggest, is that you try and look at these books and see which fits your needs the best. Again maybe someone else reading this can give you their opinions on these books.

As for documentation about more specific things, each vendor providing an OpenMP compiler and runtime should document it's workings. The OpenMP spec is the basic guideline and while terse, it does provide the basic information. The "questionable" areas may not be documented as well by all vendor's, but you can ask general questions here and more specific questions at each vendor's web site (or if you have a support contract through that mechanism). This forum is available for everyone to use - though only a few of the vendors really monitor it (rather spending time monitoring their own web site forums for questions).

The STL push_back function is a perfect example of what I mean. I haven't looked at the documentation for PGI to see what they say about this - since you only just told me that you were using their compiler. I am only guessing that this is the problem, based on what I have seen from other vendors (and my own company's implementation of the STL). It may be that this is not the problem at all - but looking at your code there isn't much else I can see that could be the cause of it. Looking at the PGI documentation is the only way to be sure - though like I have said before - this might not be as clear as you would hope. Terms like "thread safe" or "MT safe" are not as well defined as you might think. While a library may be said to be "thread safe" - meaning that multiple threads can call it at the same time - the structures that they create may not be.

[sjlee]

sNames is a static variable. So it is being shared by every thread that calls this function. std::vector is not a thread safe object. If multiple threads call this function, any access to sNames must be protected by a semaphore (mutex, lock, ...). So you need to protect all calls to sNames.size(), sNames.at(), and sNames.push_back().