Hi, Alexandra (Sasha) Fedorova wrote: > Eric, > > Thanks for the explanation. What I don't understand is this statement: > >> The clock thread >> can block (for example, in trying to grab a lock that's already held), >> but that's different from being preempted > > If the clock thread is blocked, it will go to sleep and relinquish the CPU > -- and that necessarily implies preemption. What am I missing?
"Preemption" in Solaris refers to involuntary actions applied to a thread via some external means; it does not apply to the case of a thread choosing to give up cpu or choosing to perform an operation that may involve a sleep (such as a mutex_enter on an adaptive mutex). It's important to realize that the clock thread is not responsible for waking up sleeping threads, eg those sleeping on a mutex, and in particular would not be required to wake itself up when it blocks on an adaptive mutex. The "external means" is usually some scheduling decision made on another processor, or in the clock tick processing. For example a thread may become runnable as the result of say a cv_signal and in that cv_signal processing we will transition the thread to wakeup from state TS_SLEEP to TS_RUN (ready to run) and if it has higher priority than what is currently on cpu we'll preempt the thread on cpu to tell it to make way. Or in clock tick processing we may decide that a thread has used its quantum and that there is somebody else who needs to run now, so again we poke it off of cpu via preemption. The comment you refer to may be explained by a read of the source to kpreempt(): Cheers Gavin _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
