launch a thread only if a core is available, possible ?

[pf shadoko]

I would like to know if it is possible to launch a thread only if a core is available.
for my 3D scenery, I modify the level of mesh detail in a thread
no problem if its execution is delayed, but what bothers me is freezing the main thread
currently, I only launch a thread if the number of threads currently running (launched from PB) is less than the number of cores -1
but this sometimes freezes the machine for a few moments, which is annoying for some action games (like car racing).

[mk-soft]

Looks like your threads are programmed without delays and thus bring the processor to a boil and thus no computing power remains for the GUI and system.

[pf shadoko]

yes, that's why I'm asking this question

[mk-soft]

Then you should have a look at your thread processing. Threads should not run in a continuous loop without delay.
If threads are dependent on each other, work with semaphores.

[pf shadoko]

well, I'll rephrase my question:
is there any way of knowing if a core is available?

[mk-soft]

No,
the threads are distributed by the OS core system. This means that all cores are always used. Some more, some less depending on the omission of the system

[idle]

you can try SetThreadAffinityMask on windows to bind a thread to a logical core.
and also set the priorities but you really should put a delay(0) in the loops, so context switches can be handled nicely
and use a semaphore so the thread can be created then woken up to do job and go back to the wait.

Code: Select all

PriorityClass = GetPriorityClass_(GetCurrentProcess_());
Priority = GetThreadPriority_(GetCurrentThread_());
SetPriorityClass_(GetCurrentProcess_(), #REALTIME_PRIORITY_CLASS);
SetThreadPriority_(GetCurrentThread_(), #THREAD_PRIORITY_TIME_CRITICAL);
SetThreadAffinityMask_(GetCurrentThread_(),1) ;<core number?

[PBJim]

you can try SetThreadAffinityMask on windows to bind a thread to a logical core. and also set the priorities but you really should put a delay(0) in the loops, so context switches can be handled nicely and use a semaphore so the thread can be created then woken up to do job and go back to the wait.

It would be good if the documentation for Delay() is extended to include this important background that you've mentioned here. It would be easy for someone to assume that Delay(0) does nothing, but the Windows API documentation offers this useful pointer in the first sentence :

A value of zero causes the thread to relinquish the remainder of its time slice to any other thread that is ready to run. If there are no other threads ready to run, the function returns immediately, and the thread continues execution. Windows XP: A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution. This behavior changed starting with Windows Server 2003.

A value of INFINITE indicates that the suspension should not time out.

Source — https://learn.microsoft.com/en-us/windo ... hapi-sleep

Interesting also, "... to relinquish the remainder of its time slice to any other thread" could suggest Delay(0) is not necessary in order for the context switch to happen, since it is allocated a finite time slice anyway, if I'm to understand that correctly.

[idle]

It's important for threads running on the same logical core. If you say I'm done the other threads on that core can run before your time slice is up. It's no point sitting idle spinning on wait looking around the room looking at the clock and twiddling your thumbs....when another thread could be using that time.

[PBJim]

... If you say I'm done the other threads on that core can run before your time slice is up. It's no point sitting idle spinning on wait looking around the room looking at the clock and twiddling your thumbs....when another thread could be using that time.

If a thread remained idle, in that way Idle , we’d almost certainly include provision for a delay as a matter of course anyway, but I was thinking in terms of threads that are started specifically to perform a task, complete it promptly and then terminate. Perhaps similar to the OP’s case.

I'm sure you're right, that delays are important, but I find that for my own work, which is largely traditional intensive data processing , Delay(0) increases the processing time somewhat.

[idle]

... If you say I'm done the other threads on that core can run before your time slice is up. It's no point sitting idle spinning on wait looking around the room looking at the clock and twiddling your thumbs....when another thread could be using that time.

If a thread remained idle, in that way Idle , we’d almost certainly include provision for a delay as a matter of course anyway, but I was thinking in terms of threads that are started specifically to perform a task, complete it promptly and then terminate. Perhaps similar to the OP’s case.

I'm sure you're right, that delays are important, but I find that for my own work, which is largely traditional intensive data processing , Delay(0) increases the processing time somewhat.

I mean when you have a semaphore or a spin lock at the head of the thread loop, so if your thread can complete within the time slice you can call delay(0) or SwitchToThread_() which appear to be the replacement.
I didn't know delay(0) had changed behaviour on windows.
I try my best to be idle, wife has other ideas though

[PBJim]

I mean when you have a semaphore or a spin lock at the head of the thread loop, so if your thread can complete within the time slice you can call delay(0) or SwitchToThread_() which appear to be the replacement.

Ah, I see what you mean. I'd always do something like this, which enters a delay and only wakes up to check status, as a matter of principle :

Code: Select all

      waitend.i = ElapsedMilliseconds() + timeout.i
      While ElapsedMilliseconds() < waitend.i
        Delay(1000)
        
        If TrySemaphore(x)
		   ; Do something here

        EndIf
      Wend

[idle]

yes so you could do this

Code: Select all

  Repeat 
   If WaitSemaphore(x)
     ; Do something here
   EndIf
   SwitchToThread_() 
 Until done 

so your thread waits until signaled and then bail out so another thread on the same core can run