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

[Svatopluk Kraus]

Think about td_lock like something what is lent by current thread owner. If
a thread is running, it's owned by scheduler and td_lock points
to scheduler lock. If a thread is sleeping, it's owned by sleeping queue
and td_lock points to sleep queue lock. If a thread is contested, it's
owned by turnstile queue and td_lock points to turnstile queue lock. And so
on. This way an owner can work with owned threads safely without giant
lock. The td_lock pointer is changed atomically, so it's safe.

Svatopluk Kraus

On Thu, Sep 12, 2013 at 12:48 PM, Dheeraj Kandula <dkandula at gmail.com>wrote:

> Thanks a lot Alfred for the clarification. So is the td_lock granular i.e.
> one separate lock for each thread but also used for protecting the
> scheduler variables or is it just one lock used by all threads and the
> scheduler as well. I will anyway go through the code that you suggested but
> just wanted to have a deeper understanding before I go about hunting in the
> code.
>
> Dheeraj
>
>
> On Thu, Sep 12, 2013 at 3:10 AM, Alfred Perlstein <bright at mu.org> wrote:
>
> > 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
> >
> >
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>