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

[Dheeraj Kandula]

Great. Now I understand it better. Thanks for the reply Svatopluk.

Dheeraj


On Thu, Sep 12, 2013 at 8:30 AM, Svatopluk Kraus <onwahe at gmail.com> wrote:

> Yes, td_lock is a bit of magic and not used like ordinary mutex certainly.
> And more, some dirty (not standard and hidden) things happen to it at least
> during task switch.
>
> Svatopluk Kraus
>
> On Thu, Sep 12, 2013 at 1:16 PM, Dheeraj Kandula <dkandula at gmail.com>wrote:
>
>> 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"
>>>>
>>>
>>>
>>
>