Date: Thu, 12 Sep 2013 07:16:20 -0400 From: Dheeraj Kandula <dkandula@gmail.com> To: Svatopluk Kraus <onwahe@gmail.com> Cc: Alfred Perlstein <bright@mu.org>, freebsd-arch@freebsd.org Subject: Re: Why do we need to acquire the current thread's lock before context switching? Message-ID: <CA%2BqNgxT68eobU%2BG4AjKeU6wZb0xM_sktDdQ=jCcmYyzQR%2Basiw@mail.gmail.com> In-Reply-To: <CAFHCsPXJkxvJrhfbZt5T=Bm=ZS8-%2BE9xL1cY7b6UENHJ74YR5Q@mail.gmail.com> References: <CA%2BqNgxSVkSi88UC3gmfwigmP0UCO6dz%2B_Zxhf_=URK7p4c-Ghg@mail.gmail.com> <523168EE.4070508@mu.org> <CA%2BqNgxS7RHj2LpdyADhgyjSDYfZDJODgyjV4m1yT6o5DchHQ-w@mail.gmail.com> <CAFHCsPXJkxvJrhfbZt5T=Bm=ZS8-%2BE9xL1cY7b6UENHJ74YR5Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks a lot Svatopluk for the clarification. Right after I replied to Alfred's mail, I realized that it can't be thread specific lock as it should also protect the scheduler variables. So if I understand it right, even though it is a mutex, it can be unlocked by another thread which is usually not the case with regular mutexes as the thread that locks it must unlock it unlike a binary semaphore. Isn't it? Dheeraj On Thu, Sep 12, 2013 at 7:04 AM, Svatopluk Kraus <onwahe@gmail.com> wrote: > 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@gmail.com>wro= te: > >> 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@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 select= ed >> >> thread, why is the current thread's lock acquired before context >> switch =96 >> >> mi_switch() is invoked after thread_lock(td) is called. A thread at a= ny >> >> 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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BqNgxT68eobU%2BG4AjKeU6wZb0xM_sktDdQ=jCcmYyzQR%2Basiw>