IA-32 build Thread model Free in HKEY_CLASSES_ROOT\Wow6432NODE\

[William_G_]

Hi,

I have Windows 7 professional service pack version 1

Intel Core TM i72760 QM CPU 2.40GHZ

Visual Studio 2005

Visual Fortran version 10 for windows

IA-32 Build

I have an application that works just fine when the Threading model is Apartment.

The application is called from a c++ interface. 

The interface transfers the name and path of the source data file, and some other

simple run paramaters into the target fortran dll.  

The target fortran dll performs long and complicated calculations, also calling other fortran dlls, and c++ dlls, and then passes a simple set of results back to the calling interface.

Now the user wants to go with a registry setting of Free for the threading model

as shown below:

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{834EE1F7-94F0-4946-8759-BDECED57CC3E}\InprocServer32

Change the "ThreadingModel" value to "Free".

This does not work at all.

It looks the Fortran dll is attempting to start the first 4 source

data files, but is jumping into the 5th data file without doing preliminary initializations.

There is no orderly flow in the debugger to follow.

Is there a simple way to get this working multithreaded  set to  Free in the registry as above??

Or does the application have to be rewritten to provide special 'thread safe' memory allocations??

Are there any textbooks that can be ordered from amazon that would show a multithread application

that opens a file, reads it, performs calculations, and then passes the results of the calculations??

Thanks for your help

Bill

[Steven_L_Intel1]

I had heard of these threading models but had no idea what they were. It seems to be related to synchronization by COM. In the apartment model, each call is single-threaded with synchronization, whereas with free the application can do whatever it wants.  Maybe your Fortran DLL needs to be built with /libs:dll /threads /reentrancy:threaded (I don't think this was the default back in 10.0) so that the run-time library doesn't step on itself.

I'd also suggest adding some logging to your DLL so you know what it is doing.

Of course, it would probably also be of benefit for you to use a compiler that is less than a decade old.