Date: Thu, 12 Sep 2013 00:10:38 -0700 From: Alfred Perlstein <bright@mu.org> To: Dheeraj Kandula <dkandula@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: Why do we need to acquire the current thread's lock before context switching? Message-ID: <523168EE.4070508@mu.org> In-Reply-To: <CA%2BqNgxSVkSi88UC3gmfwigmP0UCO6dz%2B_Zxhf_=URK7p4c-Ghg@mail.gmail.com> References: <CA%2BqNgxSVkSi88UC3gmfwigmP0UCO6dz%2B_Zxhf_=URK7p4c-Ghg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?523168EE.4070508>