What on earth is this multi-threading stuff?

[WSinc]

I am trying to run a simple numerical integration program, and it is giving me a strange error I've never seen before.

It's getting into a "multi-thread locking routine" and generating an unhandled exception error. I don't have any intention of using multi-threading whatsoever.

When I remove the DO WHILE loop (just have it run thru the code once) the problem disappears.........

Anyway, there is no reason why I'd want to use multi-threading, and I don't see why it would force that on me.
There are only two executable statements in the loop, and this problem appears even after I do a CLEAN and rebuild.
So I don't think it's the subroutine interface.

Is there a way to PREVENT this?

***********************************************************************
subroutine testRK()

implicit none
parameter NVAR=4
real*16 y(NVAR),yd(NVAR),t,dt
!
print *,"t,dt="
read *,t,dt
do while (.true.) ! this causes the problem
call rkstep(y,yd,t,dt)
print 101,t,y,yd
101 format(5f20.12/20x,4f20.12)
end do
return
end

[Steven_L_Intel1]

Can you give more details about the error you're having? Which version of VS are you using? While you are not using multithreading, the run-time libraries are "thread-safe" and have code to protect themselves when threading is in use. An exception should not occur - perhaps you have an error in your code that is corrupting data somewhere.

[WSinc]

Quoting - Steve Lionel (Intel)

Can you give more details about the error you're having? Which version of VS are you using? While you are not using multithreading, the run-time libraries are "thread-safe" and have code to protect themselves when threading is in use. An exception should not occur - perhaps you have an error in your code that is corrupting data somewhere.

I think I've found the problem -

One of the variables in the subroutine I called was not REAL*16, it was REAL*4.
But what I don't understand is why the interface checking feature did not catch that.

I had both Warn-interface AND GEN-interface turned on, and did a CLEAN and REBUILD before I started execution.

The VS I'm using is 2008.

Yours; Bill

[Steven_L_Intel1]

Hard to say. If the order of compilation that VS chose didn't build the subroutine first, that could happen. Glad to hear you sorted it out. In the future, I suggest using module procedures so you'll always have an explicit interface.