forums.silverfrost.com

[Abhishek]

Hi

I am creating a .NET dll from existing source code. The existing source code has some common block variables for passing data between subroutines.

As I understand, all functions and common block variables will be static. In such a case, if multiple threads call the same function, results may be jumbled up due to these common block variables.

Is there a solution to the above problem ?

Thanks
Abhishek

[PaulLaidler]

Are you sure that you mean multiple "threads". You proably mean multiple "processes" in which case there will be no problem.

You only used multiple threads when you intend to use the same common data. You can do this and there is information about this in the help file.

[Abhishek]

I mean multiple threads because I have a dll that is called inside a VB.NET executable.

The common block variables exist in the legacy code that I converted to dll and are used to access shared data by the subroutines inside the dll.

My question is whether there is some way to encapsulate these subroutines inside a class so that I can instantiate a different object for each thread.

[Abhishek]

Any ideas on this one ?

[DrTip]

Not done a lot of threading with FTN95.Net but...

as with any .net threading application accessing the same data block you need to control the order of program flow using locks and mutators etc.

I don't have an example link to give you but my book Professional C# 2005 with .NET 3.0 by Nagel et al has a good chapter on this. (Chpater 1

You don't really give enough info to give a proper answer.

basically you need to identify which blocks of code should only be called by a single thread at any one time and lock out the other threads.

There are .NET objects for this Mutex and Monitor which I guess you could use from FTN95.NET if you need to (though I would try and veer against this if you can) , I would always try and minimise the amount of data that needs to be accessed by multiple threads before resorting to using them,

[Abhishek]

Actually I have some FORTRAN functions/subroutines which have lot of common block variables. These common block variables are required so that subroutines can share data.

I am calling some of these functions from my main program (VB.NET) and these inturn call some other subroutines .. so its really a complex network of subroutines where it is impossible to reduce no. of common block variables.

In such a case, if I have to lock some portion of code, it really means all functions have to be single threaded.

I was looking for a solution where I can somehow encpsulate all of these functions and shared variables inside an object. So I can instantiate multiple objects and assign one object to each thread that needs to access these functions.

I hope its more clear now.

Thanks

[DrTip]

Well I am not sure I can help, other than to comment that it sounds like you have an over use of common block stuff to share data, i.e. use more parameters.

I don't think classes are part of FTN95 yet. but you can do some of what you want using modules rather than common blocks.

http://www.clear.rice.edu/mech517/F90_docs/EC_oop_f90.pdf

but how this would pan out with threads I don't know. Sorry I will let one of my more experienced and learned friends take up the slack form here I think


Carl

[PaulLaidler]

The fact that you have a dll that is called inside a VB.NET executable does not mean that you need to use threading.

For each instance of your VB executable you will get an independent copy of the dll data base. You can even use LoadLibrary in the VB code to make sure that the dll is not unloaded whilst the executable is running but I doubt if this is necessary.

[Abhishek]

I dont need to use threading for calling the dll.

I *want* to use threading to speed up execution, to execute two calculations in parallel rather than sequentially.

[PaulLaidler]

I which case the solution to your original question is to use the locking mechanism described in FTN95.chm. See .NET Platform->.NET Programming->Threads and Synchronising Threads, assuming of course that you have at least a dual core processor on your machine.

[Abhishek]

I had read that article.

LOCK is probably not an option here because practically the whole code would be under LOCK ! ... which effectively means calculation will be sequential anyways. Sequential calculation can be ensured by other means ... from the calling code.

FTN95 currently produces a class, lets say clsCalc, and then i call the methods like clsCalc.foo where foo is a method in clsCalc

If it is possible to instead be able to use something like:
Dim obj1 as clsCalc
obj1 = new clsCalc
and then call obj1.foo,
all variables etc will be specific to obj1 and I can create obj2 for Thread2.

Is above possible ?

[PaulLaidler]

If data is shared by two or more threads then you must use lock. You have no options about this.