Oliver Yang wrote:
Eric Saxe wrote:
You mean, the a13fade0 was unpinned due to block on a mutex, and
it was in turnstile before.
Later, it was placed into run queue, because the the mutex was
released by other ?
The clock interrupt was at some pointer pinning a13f7de0 (the
priority 105 thread). When it passivated because
the adaptive mutex it wanted was already held, it became a regular
thread (a13fade0), scheduled just like everyone else.
It waited in the sleep queue until the lock was dropped, at which
point clock became runnable, and was then
enqueued in CPU 0's run queue.
Good explanation, thanks! :-)
But you mentioned "it waited in the sleep queue until the lock was
dropped", but as far as I know, the thread should be in turnstile to
wait a mutex,
and only if thread wait a condition variable, it would be in the sleep
queue.
I just get it from book, I'm not sure, do you treat it as the same
thing(turnstile and sleep queue)?
No, you are right. In this case yes, the clock thread was waiting in the
turnstile. But since turnstiles use sleep queues in their
implementation, I tend
to think (and talk) about "the place where a thread goes when it's
asleep/blocked" as the sleep queue...since in either case
the thread state is TS_SLEEP. :)
-Eric
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
