Data fitting task creation/destruction does not appear to be thread safe

Data fitting task creation/destruction does not appear to be thread safe

Hi Everyone,

I'm using the data fitting routines in MKL (w_mkl_11.0.3.171) for spline interpolation. The fortran routine where these are called is used in a C++ OpenMP multi-threaded application, inside a parallel for loop for completely independent datasets.

The first attempt produced random crashes and wrong results, which suggested a possible data race. When I added a OMP CRITICAL section around the task creation (dfdNewTask1D) and destruction (dfDeleteTask) the code started working perfectly, producing the same results as the single core invocation.

I think the task creation and destruction is not currently thread safe, but a (admittedly quick) look at the manual did not warn about this.

Is this a known issue?

Thanks and regards,
Federico 

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I could find no mentions of a known problem, but I'll contact the developers to see what they say.

Todd, should I open a premier support ticket?

Thanks,

Federico

Hello Federico,

Could you please share with us a piece of code that you are running? This will help to investigate the possible issue. Is my understanding correct that you are trying to create a separate Data Fitting task in each thread in parallel for loop and this leads to crashes?

Thanks,

Victoriya

 

Victoriya,

It would be a bit of work to extract the code and I would have to do that within a Premier support ticket, to avoid pasting it here. If you are able to reproduce without this it would save me a lot of time.

You are correct that a different task is created in each thread. A C++ parallel for loop is calling various other subroutines for independent arrays. One of these subroutines makes a call to a Fortran function that creates, uses and destroys the data fitting task. All the functions use automatic or heap allocated variables and there are no static variables or fortran modules involved.

Regards,

Federico

Federico,

I've created a short C test case which should work roughly the same way as you have described. Please see attachment. The difference is that the routine which is used in threded section is written in C in my test case.

The issue wasn't reproduced with this test case (on Linux, 32-bit). Please tell me is there a big difference between what you are doing in you application and my test case?

Meanwhile I will modify the test case to move the routine which is used in threaded part from C to Fortran.

Thanks,

Vika

Attachments: 

AttachmentSize
Downloadtext/x-csrc test.c3.04 KB

Federico,

I've modified the test case to have a fortran subroutine which is called from C-written OMP for loop in main function. Please see attachments. File "test_f.c" contains main C function with OMP for loop; "interp.f" contains Fortran subroutine which performs interpolation.

The issue wasn't reproduced with this test case on Linux, 32-bit. Maybe you could modify the test case to see the issue, and send it back to me? Also tell me please on which OS do you see the issue?

You could build this test case using following commands:
ifort -openmp -c -ointerp.o -I${MKL_ROOT}/mkl/include interp.f
icc -openmp -c -otest_f.o -I${MKL_ROOT}/mkl/include test_f.c
icc -otest_f.out test_f.o interp.o -Wl,--start-group ${MKL_ROOT}/mkl/lib/ia32/libmkl_intel.a ${MKL_ROOT}/mkl/lib/ia32/libmkl_sequential.a ${MKL_ROOT}/mkl/lib/ia32/libmkl_core.a -Wl,--end-group ${MKL_ROOT}/compiler/lib/ia32/libiomp5.so -lpthread -lifcore

Thanks,

Victoriya

 

Attachments: 

AttachmentSize
Downloadtext/x-csrc test-f.c1.67 KB
Downloadapplication/octet-stream interp.f1.96 KB

Victoriya,

thanks for following up.
I built your the C / Fortran test case and have some updates.

Turns out that the issue is that if I compile the fortran library without openmp support I have random crashes, but if I build it with openmp support everything works fine.

So my solution of adding OMP CRITICAL sections worked not because of the addition of a critical section, but because of the linkage of omp inside the fortran routine.

However, I'm a bit surprised, as the fortran library itself is not making any reference to omp, while it's the program that consumes it that is parallelized with omp. Is this supposed to happen?

I'm using windows with Visual Studio 2010 and these versions of intel tools: w_fcompxe_2013.3.171 w_fcompxe_p_13.1.1.171 w_mkl_11.0.3.171

To reproduce in Linux I guess you would remove the -openmp to the fortran compilation line.

Thanks and regards,

Federico

Federico,

You are right, if I remove -openmp option from the command line, then the random crashes will appear on Linux also. This happens beacuse local variables of the subroutines and functions in Fortan are not thread safe by default. Please declare your Fortran subroutine as RECURSIVE or use /Qopenmp, /auto or /reentrancy:threaded compiler options to solve the issue.

Here is the forum topic which describes the related issue, you could find it useful: http://software.intel.com/en-us/forums/topic/270572

Thanks,

Victoriya

Leave a Comment

Please sign in to add a comment. Not a member? Join today