OMP: Error #136: Cannot create thread ( and #6, #8, #178 ) - Fortran project that reproduces the problem attached

[SergeyKostrov]

Fortran project that reproduces the problem ( OMP errors ) attached. Output is as follows:

...
Matrix multiplication test
Enter No of ROWS / COLUMNS in A and B matricies ( integer ):
Recommended values: 1024, 2048, 4096, 8192, 16384, 32768, 65536, etc
32

Dimensions of matrices:

No of rows    N = 32
No of columns N = 32

Initializing...
Done...
Calculating...
OMP: Error #136: Cannot create thread.
OMP: System error #8: Not enough storage is available to process this command.
OMP: Error #178: Function GetExitCodeThread() failed:
OMP: System error #6: The handle is invalid.
...

Notes:

- Win32 Release configuration needs to be used
- Options:

Fortran:
Optimization -> Parallelization = Yes ( /Qparallel )
Libraries -> Use Intel Math Kernel Library = Parallel ( /Qmkl:parallel )

Linker:
System ->
Heapk Commit = 268435456
Heap Reserve = 268435456
Stack Commit = 268435456
Stack Reserve = 268435456

268435456 = 256MB

- In total 1GB is reserved and ~1GB is still available for processing

[jimdempseyatthecove]

Sergey,

You have a case where "Virtual Memory" != "Virtual Memory" (a seamingly invalid statement).

System Total Virtual Memory is the address space available to the system expressed in 64-bit. This happens to be Page File Space + Physical Memory. The sysem can piece out any of this memory to any mix of 64-bit and 32-bit applications. A 64-bit could concievably use 64-bits of address space, but processor design may reduce this (52-bits, 48-bits, ??-bits). The processor on your system may be restricted to ~1TB of address space, however, the O/S is set up to provide only 128GB to the system.

Now comes the important part. Your choice of application is to make a 32-bit application to run as 32-bit application within 64-bit system. 32-bit programs have 4GB of addressability, however, on Windows 2GB of this addressability is reserved for (32-bit) O/S purposes (1GB if using large address). This means your 32-bit application onyl has 2GB of addressability (Virtual Memory) which can be placed anywhere in the 128GB of the Virtual Memory available to the 64-bit O/S.

The block you highlighted in red on lower left part of screen indicates Insufficient Virtual Memory _inside_ your available 2GB of Virtual Memory.

Reduce your stack size requirement.

Jim Dempsey

[Bernard]

All virtual memory allocations which is done by user mode application end up calling VirtualAlloc API functions.When Memory Manager(which sits below VirtualAlloc) sees that system is running low on memory null pointer is returned to the caller.When 32-bit application runs in 64-bit Windows that application is given full 32-bit address space.On 64-bit Win application can use up to 8TB of address space.There is also some PTE related overhead on 32-bit and 64-bit versions of Win OS and moreover system resources need also be taken into account(like paged and non-paged pools MMIO space, PTE's).There is also a difference between reserved and commited memory.Commited memory is the sum of physical memory and page file,but sometime a process will fail to allocate 2GB limit because not whole physical memory address space available for the process will be commited by the OS at any moment.

[SergeyKostrov]

Intel software engineers should take care of the problem if they consider it interested. I think the discussion is over.

[Steven_L_Intel1]

I have not yet seen any evidence that there is a problem for us to solve. I can't reproduce a problem with sane values for the linker settings. As I wrote earlier, I think you used those settings in an attempt to get around 32-bit addressing space limits, but it just made things worse.