thread scheduling priority

[Petri Helenius]

Daniel Eischen wrote:

>First, you should say what threading library you are using.
>I'll answer assuming you are using libkse (if you aren't, ignore me).
>  
>
I'll blame the heat for not mentioning that :-) Yes,
I'm using libkse.

>Try forcing libkse to use one KSE.  By default, libkse will
>create as many KSEs as CPUs that you have.  It is possible
>
Actually it seems that it creates double the amount, because of
the HypeThreading junk, although I have the logical secondary
cores halted. I still believe it's a mistake not to allow them to
"go away" altogether but have them configured confusing things
like system utilities and in this case, libkse;
# sysctl kern.threads.virtual_cpu=1
kern.threads.virtual_cpu: 4 -> 1

>that there is a problem with trying to keep both KSEs active
>when you only have 2 threads and one or more of them block
>or sleep.  To do this, set kern.threads.debug=1 and
>kern.threads.virtual_cpu=1:
>
>	# sysctl kern.threads.debug=1
>	# sysctl kern.threads.virtual_cpu=1
>
>Also, the default scheduling policy is SCHED_RR and the RR
>interval is 20msec.  If your main thread is in a busy loop,
>no other threads will run for 20 or so msec (assuming 1 KSE).
>  
>
Is there a way to hand over the mutex to the other thread when it's unlocked
by the main thread? pthread_yield? Is that a no-op if there is no other 
runnable
thread? I'd rather have both threads running while they can, using both 
CPUs.

I assume the "correct" setting for virtual_cpu in my case would be 2 ?

Pete

obviously the other option is to