hmmmm ....
Well, then the approach with the lowest level queue for Daemon threads which just do their work if there is nothing else to do, is a friendly one. and if they all are blocking, the idle thread is chosen (sleep little cpu...)
On the other hand:
the idle thread wouldn't block or so because of the wake up actions. It just looks into some queue whether there is someone to kick and then drops to hlt. Just a weird idea of me.
Benchmarking and Speed profiling
-
Schol-R-LEA
Re:Benchmarking and Speed profiling
Well, there shouldn't be any reason for the null process to do that; indeed, it would be a violation of the principle of information hiding (i.e., of the process queues) to do so, and depending on how it is done, a possible risk to memory protection as well. Again, the whole idea is that the scheduler wouldn't serve up the null process unless there were no other active processes to run, and it would be redundant for the null process to do a scheduling pass as well.BI lazy wrote: hmmmm ....
Well, then the approach with the lowest level queue for Daemon threads which just do their work if there is nothing else to do, is a friendly one. and if they all are blocking, the idle thread is chosen (sleep little cpu...)
On the other hand:
the idle thread wouldn't block or so because of the wake up actions. It just looks into some queue whether there is someone to kick and then drops to hlt. Just a weird idea of me.
I expect you know this, but just to clarify: there is a difference between a process that is blocking (waiting for a specific event, such as a timer interrupt or a message from another process) and one which has been suspended by the scheduler while other processes are run. A suspended process can be served up whenever the scheduler assigns it a time-slice; a blocking process can't run until the event it is waiting on has occurred, at which point it is changed to suspended and scheduled as normal.
-
BI lazy
Re:Benchmarking and Speed profiling
@Schol-R-Lea-san:
oichi suru - not completely correct in this context, but it is a greeting ]:->
I do not agree completely:
Information hiding in kernel space is like having a fatso ducking behind the smallest birch standing in a bunch of trees. Hmmm ... and hiding the process queues from a thread in kernel space: True, that not any thread has to fiddle around with process queues under usual circumstances. It isn't of their affairs to fiddle with process queues. But some threads have to fiddle with 'em: System thread for process creation/deletion f. ex. It is a thread that gives cpu up when it has finished it's work. so no harm happens.
But for gods sake, I won't stay silent: If the whole system is designed in a way that the idle thread is in kernel space (it must, actually, to be able to say HLT), then why not use this damned thing (sorry for my clatchian) for some other nitty gritty every bodyelse is forbidden to do? Tell me, what is the witz of a thread that doesn't do anything? f. ex. I use it to init the preloaded driver threads: someone has to load them.
BTW: In my OS, even the round robin threads get more often deprived of the cpu because they have to wait for IO than they spin around the cpu. So, the *difference* is clear to me from the very beginning on. It had to be.
And of course, I might repeat my self and of course I might walk in other well trodden clichees and no I am not busy in black printing business. That's gutenbergs affair. But don't you tell me that you are not walking in well trodden clichees, hm?
stay safe.
ps: I didn't mention what kind of queue the idle thread would walk throu': Not any process queue. It shall be a kind of 'event list', according to which the thread sends messages to the threads it has to wake up. That's the whole secret behind it.
oichi suru - not completely correct in this context, but it is a greeting ]:->
I do not agree completely:
Information hiding in kernel space is like having a fatso ducking behind the smallest birch standing in a bunch of trees. Hmmm ... and hiding the process queues from a thread in kernel space: True, that not any thread has to fiddle around with process queues under usual circumstances. It isn't of their affairs to fiddle with process queues. But some threads have to fiddle with 'em: System thread for process creation/deletion f. ex. It is a thread that gives cpu up when it has finished it's work. so no harm happens.
But for gods sake, I won't stay silent: If the whole system is designed in a way that the idle thread is in kernel space (it must, actually, to be able to say HLT), then why not use this damned thing (sorry for my clatchian) for some other nitty gritty every bodyelse is forbidden to do? Tell me, what is the witz of a thread that doesn't do anything? f. ex. I use it to init the preloaded driver threads: someone has to load them.
BTW: In my OS, even the round robin threads get more often deprived of the cpu because they have to wait for IO than they spin around the cpu. So, the *difference* is clear to me from the very beginning on. It had to be.
And of course, I might repeat my self and of course I might walk in other well trodden clichees and no I am not busy in black printing business. That's gutenbergs affair. But don't you tell me that you are not walking in well trodden clichees, hm?
stay safe.
ps: I didn't mention what kind of queue the idle thread would walk throu': Not any process queue. It shall be a kind of 'event list', according to which the thread sends messages to the threads it has to wake up. That's the whole secret behind it.