Intel® Moderncode for Parallel Architectures
Support for developing parallel programming applications on Intel® Architecture.

Second question: communication within threads

lijianemail
Beginner
438 Views
Hi all,

This is my second question. I am working on a computer vision project in which it is desirable using a two-thread parallel structure. The first thread grabs images from a camera continuously while the seond thread obtains information from the first thread. For example, we can grab images from the first thread and for each 10 frames, we display the last one from the second thread. Currently, I am using the opencv and openmp to do this work and the original program is attached here. However, it does not work properly and I am not sure what is the problem. As I am quite new to openmp, I'd like to see your suggestions regarding this issue.

I am using a xeon 2cpu workstation with winxp system and intel c++ compiler 9.0. The opencv is with the version 4 beta.

Thanks in advance.

Jian
0 Kudos
2 Replies
Henry_G_Intel
Employee
438 Views

Hello again Jian,

In OpenMP, threads communicate through shared variables. There is no event-based signaling mechanism. Communicating through shared variables requires synchronization. Your program has data races on at least two shared variables:

  1. A thread is reading nframe on lines 60 and 65 while another thread is writing nframe on line 51.
  2. The variable image is being written by one threadon line 45 while it is being read by the other thread on line 63.
I just did a quick visual inspection of MT-SingleCam.c so there could be other errors that I missed. I encourage you to analyze your program with the Intel Threading Tools. Your program also relies on OpenCV being threadsafe. Does the OpenCV documentation comment on threadsafety?
Best regards,
Henry
0 Kudos
jim_dempsey
Beginner
438 Views

In looking at your MT-SingleCam.c program I see some potential problem areas.

1) int nframe, tid, nthreads;

nframe shared between threads and it is not specified as being shared. That is one problem with nframe. The second problem is nframe should be specified as potentialy being modified ouside the current scope (or even inside scope via alternate thread. Try using

volatile int nframe;

int tid, nthreads;

The second problem is the caputer bufferis (may be)in a state of flux while the second section is calling cvShowImage. e.g. on first pass nframe is 0 therefor nframe%10 is 0 and your code in the second sectionwill be calling cvShowImage for image 0 prior to or during the image capture of image 0. Consider changing the if statement to if((nframe-1)%10==0). This does not correct for the caputer buffer being overwritten during the display. (and remember to fix the printf to use nframe-1)

I would suggest you experiment with the code and use two capture buffers. Double buffering technique. Or two buffers - mostly single buffered with second buffer flag protected and used for the intermittant update.

if(SecondBufferReady)

{

image=cvQueryFrame(SecondCapture);

SecondBufferReady = 0;

} else {

image=cvQueryFrame(FirstCapture);

}

Decorate the code with the nframe%DisplayRefreshFrequency

If two capture buffers don't fit in with your design interests then consider moving the nframe++; statement to the line following image=cvQueryFrame. That way the two paints can happen somewhat in parallel. Still not error free but will exhibit a lower probability for problems.

Jim Dempsey

0 Kudos
Reply