Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Threading a program

dajum
Novice
593 Views
I have a big FORTRANprogram that I would like to do two things too. First, turn it into an object that I canuse from a C++ program, calling functions and setting data within the program, and then executing, and being able to query results. And be able to have multiple copies of the program running at once. Can anyone suggest an approach to take?

Thanks
0 Kudos
5 Replies
Steven_L_Intel1
Employee
593 Views
You used threading in the title but I am not sure if that is applicable.

The approach usually used is to convert the program to a DLL with routines that can be called by the main program. If this DLL is invoked by different EXEs or different runs of the same EXE, each DLL's data will be separate.

If instead you have a single EXE that wants to call these functions in different contexts and with separate data, that's a bit harder. First, you must add the keyword RECURSIVE to every subroutine or function, or compile with the /recursive option. Second, do not use COMMON or module variables or SAVE or variables that are given compile-time initial values. Third, keep context data in a variable that is allocated and passed back and forth.

A more daunting approach is to create a COM server DLL out of your program - this will make it available to C++, VB.NET and C# as one or more "methods". I don't recommend this unless you're really up on COM, but if you do try it, you'll be using the Fortran COM Server Wizard to get started.

I hope this helps.
0 Kudos
dajum
Novice
593 Views

If I take the DLL route, isn't there an issue with unit numbers? Aren't all unit numbers the same for each DLL? We open and close many files during each run, with some open the entire run. Will there be conflicts since each DLL will be using the same unit numbers at the same time?

We actually would like to build a separate DLL for each run since the logic within the each run can vary. My thoughts were to compile andstart each DLL running in a different thread, each using its own set of data that would be read from input files, and actually contain slightly different code. Many of the solution routines are the same, but with slightly different routines in each DLL. But IO is the main concern and how that works.

For cases where the logic is all identical, and only some input variables change, wouldCOARRAYS be a good alternative? It seems that would take a considerable amount of source changes, where different DLL's wouldn't really require any differences. And we make extensive use of both common blocks and modules.

0 Kudos
Steven_L_Intel1
Employee
593 Views
If you are calling DLL routines in different places from the same EXE, then yes, they share unit numbers. If you are calling a DLL from different runs of an EXE, or different EXEs, then they are independent. Threads don't help you here - you still have global data in the run-time library for I/O. You could use the new NEWUNIT= keyword in OPEN (an F2008 feature) to assign an unused unit at the start of an "operation" and then close it when done, keeping track in a context variable.

Coarrays don't sound like a good fit for you. That's when you have a single set of data that you want to act on in pieces and in parallel.

It sounds to me as if you might be better off keeping the program as an EXE and invoking it using CreateProcess or ShellExecute, with some sort of input parameter file specified for each instance that tells it what to do.
0 Kudos
dajum
Novice
593 Views
The reason we would like to turn them into a DLL is to expose routines and logic to our User Interface so that we can get do both pre and post-processing of a run. Especially preprocessing that needs to be able to compute items that provide different input options. Things that now take some trial and error and multiple runs. We could easily compute them, but only when we know the specific logic that is to be used. Hence using a DLL.

Does the NEWUNIT option recycle the file number as soon as a file is closed? Sounds like you would have to use NEWUNIT for every open statement, since if some opens used spefic unit numbers,and that number was picked by NEWUNIT and then you could get a file already open error. True?
0 Kudos
Steven_L_Intel1
Employee
593 Views
Yes, the units are recycled when closed. You would ideally want to use NEWUNIT on all OPENs, though NEWUNIT tends to pick higher unit numbers that most programs don't use.
0 Kudos
Reply