Thomas De Schampheleire wrote:
I have a related question about setfrontdq(): In my logs I see a lot of calls to this function, without them being followed by a switch() or resume(). Is it possible that setfrontdq() itself resumes the task, or is the only function that can resume a task resume()?
You need resume() to actually perform the context switch. setfrontdq() just enqueues a thread at the front of the line (for it's priority) in a run queue. The thread won't actually get on the processor until a CPU dequeues the thread and switches to it.
In the traces I got from dtrace it seems that setfrontdq is followed by switch, but I would like to make sure this always is the case...
This might be the common case, but i'm not sure if it would be always be true. For example, when we're adjusting thread priorities (perhaps periodically, out of clock()'s context)...there seems to be a case where the thread we're adjusting is in the IA scheduling class, and when we re-enqueue the thread on the new per-priority queue we'll use setfrontdq() rather than setbackdq().
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/disp/ts.c#2346 ...so no swtch()/resume() would immediately follow in this case. -Eric _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
