topic Quote:mwindham wrote: in Intel® Fortran Compiler

Interface for winnt.h InterlockedAdd and linking

MWind2 — Tue, 03 Sep 2019 03:22:44 GMT

So far I have gone into a rabbit hole. InterlockedAdd is an intrinsic to MS, not in a lib, so I guess I have to make a dll in MSVC that invokes InterlockedAdd and returns result.

Kernel32.f90 has:

jimdempseyatthecove — Tue, 03 Sep 2019 12:44:25 GMT

Kernel32.f90 has:

INTERFACE 
FUNCTION InterlockedExchangeAdd( &
        Addend, &
        Value)
import
  integer(LONG) :: InterlockedExchangeAdd ! LONG
    !DEC$ ATTRIBUTES DEFAULT, DECORATE, ALIAS:'__ifort_InterlockedExchangeAdd' :: InterlockedExchangeAdd
  integer(LONG), intent(INOUT) :: Addend ! LPLONG Addend
    !DEC$ ATTRIBUTES REFERENCE, IGNORE_LOC :: Addend
  integer(LONG), intent(IN) ::  Value ! LONG Value
    !DEC$ ATTRIBUTES VALUE :: Value
 END FUNCTION
END INTERFACE

This returns the old value prior to interlocked add

Jim Dempsey

For completeness, here are

Steve_Lionel — Tue, 03 Sep 2019 13:17:00 GMT

For completeness, here are the set of interlocked operations defined in KERNEL32:

InterlockedIncrement, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd, InterlockedCompareExchange

For coarray programs, there are a bunch of ATOMIC_xxx intrinsics, such as ATOMIC_ADD.

Also, you can use OpenMP

jimdempseyatthecove — Tue, 03 Sep 2019 14:31:00 GMT

Also, you can use OpenMP ATOMIC

!$omp atomic capture
oldValue = x
x = x + expression

! .OR.

!$omp atomic capture
x = x + expression
newValue = x

The first returns prior value, the second returns resultant value.

Jim Dempsey

@jimdempseyatthecove:

MWind2 — Tue, 03 Sep 2019 18:35:50 GMT

@jimdempseyatthecove:

Thanks, I did not know about source like kernel32.f90. I was dumbin'ing kernel32.lib and getting nowhere. Using the code gets

"error #6623: The procedure name of the INTERFACE block conflicts with a name in the encompassing scoping unit. [INTERLOCKEDEXCHANGEADD]".

This compiles except for the

MWind2 — Tue, 03 Sep 2019 18:44:44 GMT

This compiles except for the error#6623 above, but I would have thought I should have a CPI1 C_PTR declared and used:

INTEGER :: I0 =1
  INTEGER(C_INT), VOLATILE, TARGET :: I1 = 2
  INTEGER :: I2= 8
  I0 = INTERLOCKEDEXCHANGEADD(I1,I2)

Quote:mwindham wrote:

FortranFan — Tue, 03 Sep 2019 19:32:37 GMT

mwindham wrote:
This compiles except for the error#6623 above, but I would have thought I should have a CPI1 C_PTR declared and used:
INTEGER :: I0 =1
  INTEGER(C_INT), VOLATILE, TARGET :: I1 = 2
  INTEGER :: I2= 8
  I0 = INTERLOCKEDEXCHANGEADD(I1,I2)

You can try this, note the IA32 (effectively 32-bit) environment. On x64 (64-bit), use InterLockedExchangeAdd64.

   use, intrinsic :: iso_c_binding, only : c_long

   interface
      function InterlockedExchangeAdd(Addend,Value) result(r) bind(C, name="InterlockedExchangeAdd")
      !DIR$ ATTRIBUTES STDCALL :: InterlockedExchangeAdd

      ! MSDN function prototype:
      ! https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedexchangeadd
      ! LONG InterlockedExchangeAdd(
      !   LONG volatile *Addend,
      !   LONG          Value
      !);
         import :: c_long
         implicit none
         ! Argument list
         integer(c_long), volatile, intent(inout) :: Addend
         integer(c_long), value, intent(in)       :: Value
         ! Function result
         integer(c_long) :: r
      end function
   end interface

   ! Local variables
   integer(c_long) :: I0 = 1
   integer(c_long), volatile :: I1 = 2
   integer(c_long) :: I2 = 8

   I0 = InterlockedExchangeAdd(I1, I2)

   print *, "I0 = ", I0

   stop

end

Upon compilation, linking, and execution:

C:\Temp>ifort /standard-semantics /warn:all /stand:f18 p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 19.1.0.085 Pre-Release Beta Build 20190522
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

p.f90(5): warning #7025: This directive is not standard F2018.
      !DIR$ ATTRIBUTES STDCALL :: InterlockedExchangeAdd
------------^
Microsoft (R) Incremental Linker Version 14.21.27702.2
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\Temp>p.exe
 I0 =  2

C:\Temp>

I think the error#6623 above

MWind2 — Tue, 03 Sep 2019 20:08:09 GMT

I think the error#6623 above was a clash with something already in kernel32.f90. This works ith LOC(i1) but does not compile with the C_LOC(I1) arg. In debugger i1 is 10.

program Interlocked1
USE KERNEL32
use iso_c_binding
    implicit none

    ! Variables
  INTEGER :: I0 =1
  INTEGER(C_INT), VOLATILE, TARGET :: I1 = 2
  INTEGER :: I2= 8
  
    ! Body of Interlocked
    
    I0 = INTERLOCKEDEXCHANGEADD(LOC(I1),I2)
    !I0 = INTERLOCKEDEXCHANGEADD(C_LOC(I1),I2)
    print *, 'Hello World'

    end program Interlocked1

Thanks to all.

MWind2 — Tue, 03 Sep 2019 20:27:04 GMT

Thanks to all.

Quote:mwindham wrote:

FortranFan — Tue, 03 Sep 2019 23:39:00 GMT

mwindham wrote:
I think the error#6623 above was a clash with something already in kernel32.f90. This works ith LOC(i1) but does not compile with the C_LOC(I1) arg. In debugger i1 is 10. ..

Refer to the documentation for the non-standard LOC function, an Intel Fortran extension, and the standard-supported intrinsic function of C_LOC from ISO_C_BINDING intrinsic module (https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-c-loc) whose return type in a Fortran-standard defined derived type of C_PTR and not what the interface for InterLockedExchangeAdd expects,

Separately, the interface declaration is already to setup to do the 'work' in terms of 'pass by reference' of the first parameter in that function, so you don't need to use LOC nor C_LOC with it.

@FortranFan

MWind2 — Wed, 04 Sep 2019 01:40:15 GMT

@FortranFan

if LOC(I1) was omitted, I got exception for trying to access address 0x00000002.

Quote:mwindham wrote:

FortranFan — Wed, 04 Sep 2019 02:04:00 GMT

mwindham wrote:
@FortranFan
if LOC(I1) was omitted, I got exception for trying to access address 0x00000002.

It's straight forward with using the Windows OS included C++ function in kernel32.dll from Microsoft as shown above in Quote #7.

I'm unsure of the interface with alias '__ifort_InterlockedExchangeAdd' in Intel Fortran provided kernel32.f90 file.

@FortranFan

MWind2 — Wed, 04 Sep 2019 02:39:00 GMT

@FortranFan

Your codes works, as does mine(both compiled 32-bit). Mine requires LOC and uses kernel32.f90 interface; yours is explicit.

So does this, without TARGET:

program Interlocked1a

    USE KERNEL32
    use iso_c_binding
    implicit none
    ! Variables
    INTEGER :: I0 =1
    INTEGER, VOLATILE :: I1 = 2
    INTEGER :: I2= 8
    ! Body of Interlocked
    I0 = INTERLOCKEDEXCHANGEADD(LOC(I1),I2)
    print *, "I1 = ", I1
    end program Interlocked1a

Quote #2 was right and I got

MWind2 — Wed, 04 Sep 2019 03:37:00 GMT

Quote #2 was right and I got it wrong by trying to redo interface in kernel32.f90 in mine first time around. I am confused about what IGNORE_LOC does? It seems a LOC for Addend is needed.

Quote:mwindham wrote:

FortranFan — Wed, 04 Sep 2019 15:27:20 GMT

mwindham wrote:
Quote #2 was right and I got it wrong by trying to redo interface in kernel32.f90 in mine first time around. I am confused about what IGNORE_LOC does? It seems a LOC for Addend is needed.

If you are able to contact Intel Support, you may want to inquire with them re: Kernel32.f90 interface for Fortran. One would have thought the 'IGNORE_LOC' attribute is present in the interface so that one doesn't need to use LOC, so something appears amiss.

Jim has shown the x64

IanH — Thu, 05 Sep 2019 17:54:49 GMT

Jim has shown the x64 declaration of that routine. On x64, Windows expects this API to be implemented by a compiler intrinsic and consequently it is not exported from kernel32.dll. ifort's runtime implements the API itself - hence the alias to an ifort runtime helper routine. The declaration and implementation of that helper routine is such that LOC does not have to be used (default calling convention, the Addend argument is passed by reference, IGNORE_LOC will do what it suggests).

The definition for x86 is different - LOC is required. On x86 this API is implemented using an export from kernel32.lib, the declaration is consistent with other API's (stdcall calling convention, the argument is passed by value, consequently the value passed needs to be the address of the thing that you want to exchange and add).

But... why are you calling this API?