New Topic \"NET\"

...should be added to this forum main topics.

Here is the question: can anyone elaborate what this examples in the create_thread1@ demonstrates ? The specific functionality i am looking for is that when i launch N threads all of them wait until they finish before continuing. Is this what create_thread1@ is made for?

EXTERNAL foo
ASSEMBLY_EXTERNAL(NAME='System.Threading.Thread.Join') T_JOIN
OBJECT('System.Threading.Thread') NEW_THREAD 
CALL CREATE_THREAD1@(foo,42,NEW_THREAD)
!Do some processing...
CALL T_JOIN(NEW_THREAD)
PRINT*,'Finishing main program.'
END

SUBROUTINE foo(m)
INTEGER m
PRINT*,'In foo ',m
END

By the way the #1 question for NET: I know how to compile simple program for NET with just one line. For example compiling some simple code produces running exe file

ftn95 parallel4a.f95 /clr /link /multi_threaded

All done behind the scene and automatically. But how to initially compile and then link such programs in two steps using command prompt if the code has many subroutines? Can i compile NET specific part separately from x86? Or all must be made in just one or another platform?

When i compile the way we do in x86 mode

ftn95 parallel4a.f95 /clr /multi_threaded

i get the obj files for NET usual x86 linker does not understand

create_thread1@ returns immediately. The executable will run until the main process is terminated. My guess is that, terminating the main process will terminate any associated threads.

Normally (e.g. C#) .NET has a compilation stage but no linking stage but FTN95 is different. To overcome the problem of using Fortran in a garbage collecting environment, FTN95 has a 'linker' that locks down the Fortran memory usage. No doubt there will be problems if you try to use either FTN95 or DBK_LINKx other than on an x86 'machine'.

Thanks. My approach at this stage when i do not know all the pitfalls of NET is to apply NET multithreading parallelism in small subprograms called by the main large x86 code as a postprocessors without rebuilding the main code to be NET too (if possible).

On small testbeds parallelization using just the FTN95 NET capabilities alone looks very simple and promising, so there is no reason to jump to other NET or parallel compilers to get that. Using multi-language programming is dangerous step for code support and development (if that's not Microsoft and Intel compilers) and there must be very compelling reasons for that, i do not see any, FTN95 is completely capable of parallel computations.

To illustrate what i have and what is intended to be accomplished, imagine that the x86 code produces outputs of arrays A(i), B(i), C(i) etc (say, temperatures, densities etc as a function of coordinate) while the postptocessing NET program will use these A,B,C to make some other quantity (say, the X-ray spectrum) and work on all CPU cores. Ideally NET postprocessor can get all the A,B,C data via common block or module. Because all A,B,C are known the parallelization should be straightforward.

Of course making NET parallel postporocessor as a separate program is in principle possible but not desirable (using CISSUE etc)

So is it possible to mix x86 and NET this way? Any suggestions on compilation of x86+NET and linking together, ideally via command line compilation, will be appreciated.

Also, Paul, please consider adding 'NET' to the forum's major topics!

Am i right that the only way this could be potentially done is via wrapping NET part into DLL and call it from x86 code? And if i will use in the NET part of the code some modules created in X86 part of the code (instead of exchanging data between x86 and NET old way via common blocks) this will not work too because NET compiler does not understand modules from x86 which means that the whole code must be compiled in NET

Quoted from DanRRight Am i right that the only way this could be potentially done is via wrapping NET part into DLL and call it from x86 code?

I think it would be more straightforward to Forget .NET and use win32 api directly. I tried to use CreateThread() function from FTN95, but always got zero as return value. Maybe Paul could help with this one?

Anyway, I ended up using a simple DLL-wrapper for win32 api multithreading functions. With some quick tests, all seems to be working fine.

Example project available here

CREATE_THREAD@ and CREATE_THREAD1@ are for .NET only.

I cannot see any documented FTN95 Win32 thread functions. There is an undocumented SPAWN@ that calls CreateThread but I would have to experiment with it to see how it works.

As observed, you can call CreateThread directly. You will find it in win32api.ins.

Thanks, Paul. Do you mean directly - without NET? That would be very very very interesting because i am not sure i will succeed rebuilding to NET large code versus just small demo. Any example for usage or the suggestions what are the arguments here

STDCALL CREATETHREAD 'CreateThread' (REF,VAL,REF,REF,VAL,REF) & &:INTEGER*4

Or how about making subroutine CREATE_THREAD_x86@ not for NET ?

I used SPAWN with DOS FTN77 20 years ago, but there it crashed a lot ( everything was unstable at DOS times including DOS itself). I still see these lines in the code though they are dead and are commented out.

CALL SPAWN@ (EXIT_TO_DOS_MULTITASK2,STACK,40000L,istack)

Windows is much more stable now, and SPAWN might work. But I do not see SPAWN@ in the Help though.

Also while i am still trying to get through the forest and recompile the whole code for NET (it is very tempting to get almost an order of magnitude speedup on real code) i will share my experience for those who are interested, this may save your time in future:

• NET linker dbk_link2 does not recognize third party LIB files (used for parallel algebra... i have zero hope the developer will recompile it for NET).
• Now i see why developers mostly use INCLUDE <clearwin.ins> and not USE CLRWIN or USE MSWIN. Usual x86 modules will not work under NET.
• Bad news is that /3gb option is not recognized.
• NET linker is more strict which is good because it found me few errors of argument type mismatch or calling real8 function as real4.
• Compilation stopped with weird error 'Array is too large' pointing on variable which was even not an array. Spreading and shuffling subroutines around - and the error disappears.
• And this is my final point after two days of rebuilding: [DBK_LINK Ver. 2.0.0 ] *** Internal Linker Error....
  Decreased all arrays to almost zero but this did not help. So that's a shutdown for today, will see what tomorrow brings.

By 'directly' I meant by calling into the Microsoft Windows API using CreateThread etc. To do this you can Google 'MSDN CreateThread' and work out how to pass the arguments. Jalih reports above that he has done this but I have not tried this approach myself. You can also access the same Windows API libraries via C# and this is essentially what CREATE_THREAD@ does for you.

jalih, thanks for the idea. I compiled it (one of two works) but after modifying it like in the last test in the other thread

https://forums.silverfrost.com/Forum/Topic/2239

don't seem code waits properly threads end. Can you reproduce this exactly test?

By the way have anyone tried the approach of using normal x86 FTN95 compiler while wrapping multithreading part into DLL using NET? That approach should have some advantages over complete NET approach like option for /3GB, it is more stable and well checked by orders of magnitude more users. Here could be other pitfalls but right now that looks like another simple way dealing with the threads within this compiler. FTN95 should accept NET DLL like it is doing with DLLs created by many other third party compilers. I have tried this approach but because my NET experience is near zero level i still have not succeeded.

Here what i have done, all 100% are in front of you. I created file the text of which is below called parallel_NET_DLL.f95 which 100% works under NET and compiled it this way for NET C:> ftn95 parallel_NET_DLL.f95 /clr /multi_threaded

It contains function Parallel_NET_DLL which starts threads. The analog of OBJ file for NET compiler produces is called parallel_NET_DLL.dbk

!
  integer function Parallel_NET_DLL () 
  include <clearwin.ins> 
  EXTERNAL runN 
  parameter (nThrMax=80) 
  common /threads_/nEmployedThreads, kThreadEnded(nThrMax) 


1 print*,' Enter number of parallel threads < 8' 
  read(*,*)   nEmployedThreads 
!  if(nEmployedThreads.lt.1.or.nEmployedThreads.gt.8) nEmployedThreads=4

  call clock@ (time_start) 

!...set a flag of thread finished
  kThreadEnded(:)=1 

  do i = 1, nEmployedThreads 
     CALL CREATE_THREAD@(runN,20+i) 
     call sleep1@(0.02) 
  enddo 

!...wait till all threads finish 
  do while (minval(kThreadEnded)==0) 
    call sleep1@(0.1) 
  enddo 

  call clock@ (time_finish) 

  time = time_finish-time_start
  time2= time * nEmployedThreads
  print*, 'Elapsed time, total CPU time=', time, time2

  goto 1
  Parallel_NET_DLL = 1
  END function 

! ===================================================================== 
  subroutine runN (iThrHandle) 
  include <clearwin.ins> 
  parameter (nThrMax=80) 
  common /threads_/nEmployedThreads, kThreadEnded(nThrMax) 

  ithr = iThrHandle-20
  lock;   print*,'Started thread # ', ithr ; end lock 
  d      =2.22 
  kThreadEnded(ithr) = 0 
  do i=1,200000000/nEmployedThreads 
    d=alog(exp(d)) 
  enddo 
  lock;     print*, 'Ended   thread # ', ithr  ;     end lock 
  kThreadEnded(ithr)=1 
  end 

Then i made DLL out of it this way C:>dbk_link2 /multi_threaded parallel_NET_DLL.dll parallel_NET_DLL.dbk

Then i created main program file for regular x86 mode which just calls this function Parallel_NET_DLL and compiled it usual way C:> ftn95 parallelDLLmain.f95

  integer  Parallel_NET_DLL
  external Parallel_NET_DLL
  jj   =   Parallel_NET_DLL()
  print*, 'done'
  end

At the end i linked OBJ and DLL using regular SLINK C:> SLINK parallelDLLmain.obj parallel_NET_DLL.dll

Here is BAT file if you named files as i did above

ftn95 parallel_NET_DLL.f95 /clr /multi_threaded >zftn95NET
dbk_link2 /multi_threaded parallel_NET_DLL.dll parallel_NET_DLL.dbk >zlinkNET
ftn95 parallelDLLmain.f95 >zftn95x86
SLINK parallelDLLmain.obj parallel_NET_DLL.dll >zlinkx86

I got the error that SLINK does not find the function parallel_NET_DLL. Last thing i expected is such message which means that NET DLL is not recognized. Even compiling everything for NET by taking proper dbk_link2 instead of SLINK has the same problem. What's wrong ? Linker for NET has the problem creating readable DLL or i made some mistake somewhere?

SLINK cannot link object files or DLLs compiled for .NET.

Use FTN95 (without /clr) with SLINK. Use FTN95 (with /clr) with DBK_LINKx. Use DLLs that match with the executable in this sense.

But as i wrote NET DLL does not match even with own DBK_LINK if we substitute SLINK with it! Or i am doing something wrong?

And if SLINK can not link NET DLL -- that is very pity. Why it is that? It can connect with DLLs from bunch of obscure third party compilers while can not even start the own NET program. Since this thread is in Suggestions i'd appreciate if developers investigate if launching of own NET DLLs from x86 could be potentially possible. That is specifically important to me since i can not get through to the end using NET with our large code, the compiler freaks out, linker gives up without much diagnostics, all reminds me stability of FTN90/95 around 15 years ago. More years and more users need to polish NET compiler. And needless to say that everyone will win from that. FTN95 for NET has excellent multithreading capabilities as a way for parallel calculations

I don't think that DLLs can be used as input on a DBK_LINKx command line. Try using DBK_LINKx without the DLL input.

Remember that DBK_LINKx is only a psuedo linker. Normally .NET does not have a linker. Everything is automatically linked at load time. So presumably DBK_LINKx only needs the .dbk files.

SLINK cannot be made to link .NET DLL assemblies. In this case it is not a question of time or resources. It cannot be done.

Well, all that may sound OK to CS department folks but for others it sounds a bit perpendicular to their experience and expectations from the new language. It definitely does not encourage scientists and engineers to learn and use NET. I'd say, exactly opposite, it screams to avoid it as the multilanguage programming is always not a plus for maintainability and usability of the large codes. NET looks like a dead language which became dead among the groups using Fortran by not reaching critical mass of acceptance. And its functionality is too restrictive. I feel now that probably the devotion of resources to build the NET instead of 64bit and OpenMP/CUDA capabilities was a mistake of developers of this compiler, because former does not while latter do lie on the mainstream of computers/languages evolution. Why did i use NET, did i need it? Not at all, i needed multithreading to parallelize the code. On tiny test code NET worked, on large it failed. And without large users base there will be no chance that NET will be not a dead buggy extension of this compiler. So pity because all started to great...

So what other options are left? WinAPI...

Jalih, As follows from added lines the code does not wait for proper threads completion. What's wrong?

module test
  INCLUDE <windows.ins>
  STDCALL attach_thread 'attach_thread' (REF, REF, REF):integer*4
  STDCALL wait_object 'wait_object' (VAL):integer*4
  STDCALL close_handle 'close_handle' (VAL):integer*4
  STDCALL create_mutex 'create_mutex' (VAL):integer*4
  STDCALL release_mutex 'release_mutex' (VAL):integer*4
  
  integer :: hMutex
  integer :: t(8)
  integer :: values(8) = (/1,2,3,4,5,6,7,8/)
  integer :: nEmployedThreads

  contains
    subroutine thread(p)
!      implicit none
      integer :: p, i

      i = wait_object(hMutex)
      write(*,*) 'Hello from thread ', p ! , nEmployedThreads
      i=release_mutex(hMutex)

      d =2.22 
!      nEmployedThreads = 8
      do i=1,200000000/nEmployedThreads 
       d=alog(exp(d)) 
      enddo

      call ExitThread(0)

    end subroutine thread

end module test


WINAPP
  use test
  implicit none
  integer :: i, x,  nEmployedThreads

  hMutex = create_mutex(1)
  write(*,*) 'Multithreading test'
  i = release_mutex(hMutex)

  nEmployedThreads = 8
  call clock@ (time_start)

  do i=1,8,1
    x = attach_thread(thread,values(i),t(i))
  end do

  do i=1,8,1
    x = wait_object(t(i))
  end do

  call clock@ (time_finish) 

   time = time_finish-time_start 
   time2= time * nEmployedThreads 
   print*, 'Elapsed time, total CPU time=', time, time2

END

Dan,

I am not sure what .NET does, but could you achieve the same in a win32 environment ? Could you wrap the API calls in fortran 95 wrappers and achieve what you want ? Lots of Clesarwin+ do this. You could create a library of FTN95 callable thread routines.

One of the problems with multi-thread testing is producing a non-trivial solution, as most thread examples do next to nothing significant. I have had problems converting trivial OpenMP parallel examples to meaningful solutions.

John

Quoted from DanRRight Jalih, As follows from added lines the code does not wait for proper threads completion. What's wrong?

Sorry for late reply, Dan...

Actually it was my mistake, the return value for attach_thread() is the thread handle and wait_object() should be called with thread handle as parameter.

Updated example available here

I spotted another problem: write(,) in WINAPP don't seem to be thread safe and should only be called in main thread.

Jalih, Well, definitely here is something even more wrong, may be on my side, i do not know.... It does not seem this one works at all...Please add these lines into the launching thread and see in task manager that threads do not even start

      d =2.22 
      nEmployedThreads = 16
      do i=1,200000000/nEmployedThreads 
       d=alog(exp(d)) 
      enddo

John, It's a WinAPI scenario what jalih is doing above trying to create functional testbed with thread safe locks with ability to write(,) like it is done in NET (without that all efforts would be useless because we will lose the last chance to do at least some debugging in threads). The NET way is dead for me and you because the only way i can make it work is by writing small program completely in NET, pass needed data not via common blocks or modules but via file exchange (or similar, may be, a bit better latest way transfering data via RAM allocation Paul promised) and launching NET part from x86 program using CISSUE or similar. It does not compile my program and has no /3GB. Try this testbed, John, and check it it works in your case, compilation is simple

FTN95 main.f95
slink main.obj t.dll

Quoted from DanRRight Jalih, Well, definitely here is something even more wrong, may be on my side, i do not know.... It does not seem this one works at all...

Try this multithreaded matrix multiply test.

Remember, write(,) into ClearWin window from worker thread in WINAPP application seems to lock things up, so it can't be used. Maybe Paul can help with this issue?