APLNext Supervisor - Threads Stuck in Queue

[joe_blaze]

Because at that time the Windows OS tells the Supervisor that it cannot start another thread containing an instance of the APL+Win ActiveX engine. All available resources are in use because the 'Kernel' functions are running and they do heavy work. The application is essentially cpu-bound.

[Davin Church]

So why does the OS think that all the CPU resources are in use when nearly half of them aren't really anything?

For that matter, if you ask for a thread why does the OS deny it to you even if they ARE all busy? Shouldn't it let the application worry about overloading and give you as many threads as you ask for? (That's part of what started me on this discussion in the first place.)

[joe_blaze]

Davin: So why does the OS think that all the CPU resources are in use when nearly half of them aren't really [doing] anything?
Joe: None of them are doing nothing and all of them are fully occupied in this situation.

Davin: For that matter, if you ask for a thread why does the OS deny it to you even if they [the cores] ARE all busy?
Joe: Best to ask Microsoft in this case, but I suspect that the OS has a threshold of available processing potential, below which it deems that there are not enough available processing resources to instantiate another thread.

Davin: Shouldn't it let the application worry about overloading and give you as many threads as you ask for? (That's part of what started me on this discussion in the first place.)
Joe: The applications running have saturated the available processing power of the target machine.

Machine capacity is finite and eventually that capacity is reached.

[Davin Church]

I guess it's a good thing Microsoft doesn't have me designing their system, huh?

Question: What class-method is the Supervisor using to start up these threads (to hold the APL ActiveX engines)? Maybe I can do a little research and learn something.

[joe_blaze]

Currently the Supervisor is targeted to the Microsoft .Net Framework 4.0, however the .Net Framework 4.5/4.6 provides a new model for asynchronous programming which a future release of the Supervisor may adopt. Besides more development convenience, it appears that performance may also improve because the waiting thread would be handled by the OS rather than the Supervisor. See here: https://msdn.microsoft.com/en-us/library/hh191443.aspx. By having a specific 'await' control structure in the .Net code, the OS can now be informed that the wait operation is lightweight and handle it directly. Prior to the availability of 'await', when the Supervisor application creates a wait operation, the OS has to give it the same relative priority as the actual processing task associated with that wait operation. Experiments will need to be performed to determine if the new 'async' and 'await' control structures in .Net will provide more processing power in APL+Win applications using the Supervisor.