Although your hints helped me much to understand what going on inside there, there does remain one obscure point...
As far as I can see, when resume() or _resume_from_idle() is called, the stored (gnum | cnum) context for the process is loaded from curthread->t_procp->p_as->a_hat->sfmmu_ctxts[cpu->cpu_mmu_idx] in sfmmu_alloc_ctx(). If a thread's associated proc bears an invalid context, then sfmmu_alloc_ctx() assigns the next available context number from cpu->cpu_mmu_ctxp->mmu_cnum. For sun4u machines, sfmmu_cpu_init() specifies, through sfmmu_cpuid_to_mmu_ctx_info(), that cpu->cpu_mmu_idx = cpu->cpu_seqid. All that indicates that when a thread without a good context number is switched to, it will get a unique context number for the CPU it is about to run. So, threads within the same process may have different contexts, even though they actually refer to the same address space. Also, when a thread migrates to another CPU, it will get a brand new context number, unless it has also ran previously there. Is that all right? What bothers me is that at times threads with different kthread_t.t_tid's but same contexts seem to run on the same CPU. Can a thread's tid change during its execution? jimglent -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
