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

[Dheeraj Kandula]

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 at 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 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"
>>
>
>