Why do we need to acquire the current thread's lock before context switching?

[Alfred Perlstein]

On 9/11/13 2:39 PM, Dheeraj Kandula wrote:
> Hey All,
>
> When the current thread is being context switched with a newly selected
> thread, why is the current thread's lock acquired before context switch –
> mi_switch() is invoked after thread_lock(td) is called. A thread at any
> time runs only on one of the cores of a CPU. Hence when it is being context
> switched it is added either to the real time runq or the timeshare runq or
> the idle runq with the lock still held or it is added to the sleep queue or
> the blocked queue. So this happens atomically even without the lock. Isn't
> it? Am I missing something here? I don't see any contention for the thread
> in order to demand a lock for the thread which will basically protect the
> contents of the thread structure for the thread.
>
> Dheeraj
>

The thread lock also happens to protect various scheduler variables:

         struct mtx      *volatile td_lock; /* replaces sched lock */

see sys/kern/sched_ule.c on how the thread lock td_lock is changed 
depending on what the thread is doing.

-- 
Alfred Perlstein