Make legacy code generally thread-safe (not just for OpenMP multithreading)

[Tobias_Loew]

Hi,

I've just created a topic called "threadprivate common-block for non-openmp thread".

But AFIAK fact is:

There are billions of LOC of legacy FORTRAN libraries out there that use static variables (common-blocks, safe-statements,...). Those libraries are nowadays called from C, C++, managed .net or even Java code, ... (and this is only the Windows world), in Applications that usually run on multiple threads (e.g. as server-applications).

When I made my own FORTRAN code thread-safe for OpenMP, I really liked the threadprivate statement for common blocks. But it has at least two drawbacks: first, it has to be added to every common-block and global module variable, and second (and that's a big drawback), it works ONLY for OpenMP-threads.

Having a simple compiler switch, making all static variables thread private and allocating memory on thread attach, would be of great help. I'd really like to see intel addressing this problem.

best regards

Tobias

[Steven_L_Intel1]

That would be quite a dangerous switch to add as a global option. There are many threaded programs that use static storage correctly, with protection of accesses. Making all of them threadprivate would break these programs. Also, as you point out, OpenMP is not the only threading method and what works for one method might not work for all.

Intel Inspector XE can locate inappropriate use of static storage in a threaded application. I don't see that the proposed solution helps.

[Tobias_Loew]

Hi Steve,

thanks for your reply. I see the problem with my rather brute "global switch" approach, but I hoped to start a discussion about that problem:

But my problem is the following: I've got hundreds of files of legacy fortran code packed into multiple libraries and called from C++ code. On the C++ side I prefer using threading frameworks like Boost.Thread or the new C++11 features since they allow a much better control-flow than OpenMP. Unfortunately, I don't see any way to make the fortran code thread-safe for non-OpenMP threads without ripping out all the common blocks and putting them onto the stack (or allocate on the heap). Having primitives/pragmas for thread-local variables like in OMP (or just an option to use that pragma for all threads) would help a lot.

My main goal is: make those already OpenMP thread-safe libraries universal thread-safe with minimal changes to the code.

Tobias

[Steven_L_Intel1]

I don't see an easy solution for you. You'd have the same problem if the C++ code had originally been written to use static variables. 

[Tobias_Loew]

Yes, that's true, but in C++ I've got direct API support for thread-local storage and I can do template-magic on the types to redirect read/write access to thread-private storage. Thus, I only would have to change the declaration and not every single usage.

I haven't written that old-style fortran code, I have to deal with, and I don't want to blame the guys having written it, I just want to take the code to the next level of computation.

Tobias

[Steven_L_Intel1]

You don't necessarily have to change every single usage in Fortran either. Maybe you'd need to add a THREADPRIVATE directive for the COMMONs where they are declared (in an include file, one hopes). There isn't a one-size-fits-all solution to this.

[Tobias_Loew]

Maybe I got it wrong, but my understanding (and observation) is that threadprivate directives work only for OpenMP-multithreading.

I need thread-save code for all threads running into the library.

Tobias

[Steven_L_Intel1]

Ah, I see. Yes, you are correct. You have more work to do.

[Tobias_Loew]

I got another question: Is there a way to OpenMP-fy a thread? (By letting it run into some OpenMP-section) If this was possible, then I only would have to guard the entry points to my libraries.

Tobias
 

[Steven_L_Intel1]

I don't think you can get the effect you want with adding OpenMP. The threadprivate nature of COMMON would be in effect only within a parallel region managed by the OpenMP runtime.