Thread recursive nesting test

[FORTRANS]

Hi,


Thread depth 2031 starting
Thread depth 2032 starting
^C
F:\WORK>


Windows 2000 Pro SP4
256M mem
(from system information)
261M Total physical mem
115M Available physical mem
525M virtual mem

[Slugsnack]

I got up to 2025 on Windows 7 32 bit RTM.

4GB RAM. However I am not sure that the amount of physical memory will affect the memory available to an application. That is the whole point of virtual memory and paging. In theory, every usermode application should only have access to 2GB memory

[dedndave]

the issue is the stack - each thread is alloted 1 Mb stack space by default
it has to be physical memory - not virtual
i am surprised you do not get more threads on win 7
it may be a predetermined limit

[Slugsnack]

the issue is the stack - each thread is alloted 1 Mb stack space by default
it has to be physical memory - not virtual
i am surprised you do not get more threads on win 7
it may be a predetermined limit

Are you sure stack has to be physical memory ? If it's the case that the stack is the bottleneck here because of the fact is has to be in physical memory. Then going by that theory, surely once we exhaust physical memory with this program, no other programs can create new threads ?

[hutch--]

Slugsnack,

Did you use the later mod that used your reference to MSDN, I added the constant so it then used the preset stack size and it went from 2k to 16k with no problems. I am using XP SP3 32 bit with 4 gig memory. I ran it with a much larger number but it stops creating threads at about 31k.

[Slugsnack]

Slugsnack,

Did you use the later mod that used your reference to MSDN, I added the constant so it then used the preset stack size and it went from 2k to 16k with no problems. I am using XP SP3 32 bit with 4 gig memory. I ran it with a much larger number but it stops creating threads at about 31k.

Yes, assembled the source from your post : http://www.masm32.com/board/index.php?topic=12445.msg95526#msg95526

Just tested again, stops at 2026. Also, in case it's relevant.. Page file size = 3582MB

[dedndave]

well - i have learned (the hard way - lol) that stack memory may be assigned to a thread or procedure
but not dedicated to it until it uses it - so until you actually use some of the huge stack-space, it is "available" to other threads
it seems illogical to have stack space virtualized to disk - it would constantly be switching in and out

[hutch--]

I would be surprised if stack space was shoved out to virtual memory as it would involve some serious performance hits but the Microsoft reference material appears to indicate it is a memory based limit so it appears that stack stays loaded in memory when other allocation types are swapped to disk.

It has been an interesting aside that you can create about 2000 threads but the original purpose of the test piece was to test thread nesting and the necessary overhead in the OS keeping track of all of the suspended threads so with 2000 threads nested you have 1999 wait states pending thread termination signalling which is impressive in its capacity and speed.

[MichaelW]

Watching the test app in performance monitor, the process virtual bytes rapidly increase from ~12,000,000 to ~2,000,000,000 and the process page file bytes steadily increase from ~270,000 to ~27,000,000.