Parallel Inspector & boost.thread

[simone74]

In our project we use boost.thread (www.boost.org) and windows SDK to mange thread creation and synchronization.

I'm running Parallel Inspector in windows xp 32 bit with visual studio 2008.

The Boost version is 1.36 because the latest boost version 1.40 do not seems to contain significative threading fixes.

Unfortunately Intel Parallel Inspector reports many false race conditions (expecially with boost.thread condition variables).

We already have an Intel Thread Checker license, the Checker has the same problems plus is slower to startup the analysis, thus we are evaluating the Parallel Inspector.

Is there some known boost.thread support issue in Parallel Inspector?

I'm sorry for not sending a code sample but it will require the full boost library from your side to compile (I wander if I can send a mix of source and binary files).

[simone74]

With the boost distribution there is a simple sample about condition variables.
I made a console application solution with visual studio 2008 under windows xp 32 bit consisting of a single file the Inspector finds many presumably false race conditions.
The sample is in the folder boost_1_36_0libsthreadexample of the boost distribution package.

Here is the sample code consisting of a synchronized buffer, the main code spawns 2 worker threads, the sender and the receiver. The sender post to the receiver 10 numbers through the buffer before terminating.
To run this sample you need the boost headers and 2 .lib files named (libboost_date_time-vc90-mt-gd-1_36.lib) and (libboost_thread-vc90-mt-gd-1_36.lib). You can either build the .lib from the source files in the boost distribution that is downloadable at www.boost.org or get the binary files with a full boost installer available for free at http://www.boostpro.com/download.

[cpp]// thread-test.cpp : Defines the entry point for the console application.
#include 
#include 
#include 
#include 

class bounded_buffer
{
public:
  typedef boost::mutex::scoped_lock lock;

  bounded_buffer(int n) : begin(0), end(0), buffered(0), circular_buf(n) { }

  void send (int m)
  {
    lock lk(monitor);
    while (buffered == circular_buf.size())
      buffer_not_full.wait(lk);
    circular_buf[end] = m;
    end = (end+1) % circular_buf.size();
    ++buffered;
    buffer_not_empty.notify_one();
  }

  int receive()
  {
    lock lk(monitor);
    while (buffered == 0)
      buffer_not_empty.wait(lk);
    int i = circular_buf[begin];
    begin = (begin+1) % circular_buf.size();
    --buffered;
    buffer_not_full.notify_one();
    return i;
  }

private:
  int begin, end, buffered;
  std::vector circular_buf;
  boost::condition buffer_not_full, buffer_not_empty;
  boost::mutex monitor;
};

bounded_buffer buf(2);

boost::mutex io_mutex;

void sender() {
  int n = 0;
  while (n < 10) {
    buf.send(n);
    {
      boost::mutex::scoped_lock io_lock(io_mutex);
      std::cout << "sent: " << n << std::endl;
    }
    ++n;
  }
  buf.send(-1);
}

void receiver() {
  int n;
  do {
    n = buf.receive();
    {
      boost::mutex::scoped_lock io_lock(io_mutex);
      std::cout << "received: " << n << std::endl;
    }
  } while (n != -1); // -1 indicates end of buffer
}

int main(int, char*[])
{
  boost::thread thrd1(&sender);
  boost::thread thrd2(&receiver);
  thrd1.join();
  thrd2.join();

  char l_c;
  l_c=getchar();
  return 0;
}[/cpp]

[Shwetha_D_Intel]

Quoting - simone74

In our project we use boost.thread (www.boost.org) and windows SDK to mange thread creation and synchronization.

I'm running Parallel Inspector in windows xp 32 bit with visual studio 2008.

The Boost version is 1.36 because the latest boost version 1.40 do not seems to contain significative threading fixes.

Unfortunately Intel Parallel Inspector reports many false race conditions (expecially with boost.thread condition variables).

We already have an Intel Thread Checker license, the Checker has the same problems plus is slower to startup the analysis, thus we are evaluating the Parallel Inspector.

Is there some known boost.thread support issue in Parallel Inspector?

I'm sorry for not sending a code sample but it will require the full boost library from your side to compile (I wander if I can send a mix of source and binary files).

Intel Parallel Inspector supports Intel Threading Building Blocks, Windows Threads*, and OpenMP*. The product team is exploring support for Boost threading models in future product releases. We believe most of the reported diagnostics are related to the boost threading model used in the code sample you posted.

Intel Thread Checker includes a number of APIs that a developer may insert to notify Intel Thread Checker that a particular routine or function is a barrier or lock, and the use of these APIs allows the developer to avoid generating diagnostics issues just because the analysis engine doesnt recognize your threading model. Among Thread Checker customers these are called the itt_notify APIs. The documentation is part of the Intel Thread Checker product. Intel Parallel Inspector recognizes these APIs for compatability.

[simone74]

WaitForSingleObjectQuoting - sdoss

Intel Parallel Inspector supports Intel Threading Building Blocks, Windows Threads*, and OpenMP*. The product team is exploring support for Boost threading models in future product releases. We believe most of the reported diagnostics are related to the boost threading model used in the code sample you posted.

Intel Thread Checker includes a number of APIs that a developer may insert to notify Intel Thread Checker that a particular routine or function is a barrier or lock, and the use of these APIs allows the developer to avoid generating diagnostics issues just because the analysis engine doesnt recognize your threading model. Among Thread Checker customers these are called the itt_notify APIs. The documentation is part of the Intel Thread Checker product. Intel Parallel Inspector recognizes these APIs for compatability.

Let me write some of my thoughts to have a better understanding of your reply.

The boost.thread implementation is based on windows SDK.

I added all the boost.thread implementation to the console application example that I mentioned in the previous post as a separate project in order to build the needed boost libraries.

The boost libraries are intended to work on multiple platforms but threading is platform dependent. Thus there is some preprocessorwork to select the correct code (it boils down to windows SDK or PThreads).

I wander if the problem is related to the preprocessor or the SDK functions called by the boost.thread implementation. In other words in the boot.thread implementation I can see calls to SDK shyncronization like WaitForSingleObjectand Microsoft specific intrinsics like _ReadWriteBarrier. Is the problem related to some of this calls?

I think that understanding better what is misleading the Inspector here could be of interest not only for boost users but also for Microsoft threading users.

Theitt_notify APIs sounds interesting but it seems that I need to know what are the APIs the inspector can't manage. I'll have a look anyway.

Thanks for the reply.

[weliad]

Hi,

We're experiencing similar issues as described by Simone, with the Thread Checker and Boost 1.37. Is there any news on this matter since last October?We have searched the web with no luck in finding an answer, or a sample of how to disable the notifications when using Boost over Windows.

Thanks in advance,
Liad Weinberger.

[Peter_W_Intel]

Currently Intel? Parallel Inspectorand Intel? Parallel Amplifier still don't support user's threading model (use itt_nofify_???). This feature may or may not be considered in future release.

Regards, Peter

[gmiller_w_miller]

There seems to be an issue with the windows 7 SPI call to support CONDITION_VARIABLE when doing timed wait where the inspection show issues because of calls like:

success = SleepConditionVariableCS(&cv->cv, &m->cs, msTime);

So if I implement a simple pthread function like:

int pthread_cond_timedwait(pthread_cond_t * cond_ptr, pthread_mutex_t * mutex_ptr, const timespec * time_ptr)

{

min_pthread_mutex_t * m;

min_pthread_cond_t * cv;

BOOL success = 0;

DWORD msTime = 0;

if (mutex_ptr == NULL)

return -1;

if (*mutex_ptr == NULL)

return -1;

m = (min_pthread_mutex_t *) *mutex_ptr;

if (m->signiture != 0xDEFAC810)

return -1;

if(cond_ptr == NULL)

return -1;

if(*cond_ptr == NULL)

{

if (pthread_cond_init(cond_ptr, NULL) != 0)

return -1;

}

cv = (min_pthread_cond_t *) *cond_ptr;

if (cv->signiture != 0x1F1F1F1F)

return -1;

if( time_ptr == NULL)

return -1;

// WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING

// This really should assume that the time coming in is an absolute time

// and convert that time to a realative time but I decided to deviate from

// the standard API definition.

// WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING

msTime = (DWORD)(time_ptr->tv_sec * 1000); // convert seconds to milliseconds, ignore nano sec.

success = SleepConditionVariableCS(&cv->cv, &m->cs, msTime);

return 0;

}

int pthread_cond_timedwait(pthread_cond_t * cond_ptr, pthread_mutex_t * mutex_ptr, const timespec * time_ptr){ min_pthread_mutex_t * m; min_pthread_cond_t * cv; BOOL success = 0; DWORD msTime = 0;
if (mutex_ptr == NULL) return -1; if (*mutex_ptr == NULL) return -1;
m = (min_pthread_mutex_t *) *mutex_ptr; if (m->signiture != 0xDEFAC810) return -1; if(cond_ptr == NULL) return -1; if(*cond_ptr == NULL) { if (pthread_cond_init(cond_ptr, NULL) != 0) return -1; } cv = (min_pthread_cond_t *) *cond_ptr; if (cv->signiture != 0x1F1F1F1F) return -1; if( time_ptr == NULL) return -1;
// WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING // This really should assume that the time coming in is an absolute time // and convert that time to a realative time but I decided to deviate from // the standard API definition. // WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING msTime = (DWORD)(time_ptr->tv_sec * 1000); // convert seconds to milliseconds, ignore nano sec.
success = SleepConditionVariableCS(&cv->cv, &m->cs, msTime);

return 0;}

I see issues with detecting deadlock, where there is no deadlock. Problem shows as a EnterCriticalSection() and SleepConditionVariableCS(). Which is either wrong or MS code is wrong.