From owner-freebsd-arch@FreeBSD.ORG Thu Sep 12 20:27:47 2013
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTP id 5F9BBD50;
Thu, 12 Sep 2013 20:27:47 +0000 (UTC)
(envelope-from dkandula@gmail.com)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com
[IPv6:2a00:1450:400c:c05::22c])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id B7C5E24E4;
Thu, 12 Sep 2013 20:27:46 +0000 (UTC)
Received: by mail-wi0-f172.google.com with SMTP id c10so4114681wiw.5
for <multiple recipients>; Thu, 12 Sep 2013 13:27:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=XEqEByXHjfUcs5/bJZBZJHeOeTUyc7N1mql3Z8f42is=;
b=B+xs8obAN2KPWcqkNUjmKSdh7PueMLaltG60qr+W9PKJGDgnhVtYsnX3UyAOf2oj2m
SUe2UOhT+E0ky1wrayJAgM2THkuzroGEkNNJWqW0WjFzQY085y5ChcjcOKhmlUpAxph3
pIIYYFRwZ0ZclLbLc2bmMUJ08Z2FUpfgi8xO2iFHs6GVknwNfXhy+fAkprUBAJW8DJQW
vBhdL3+SSuzyvHa2nx0xF+O2Ab752WWAhqpJ2Ox458N35xjcdyD7gm4uRWDN+JF9UK5x
3UKfdbSbgc88fSSj8NC2eQHs8FxAVUS4PqkuxdmWi7U3Zj6pby4NnXZZDaLB0MEfbnH5
jatQ==
MIME-Version: 1.0
X-Received: by 10.194.201.168 with SMTP id kb8mr2768137wjc.63.1379017665061;
Thu, 12 Sep 2013 13:27:45 -0700 (PDT)
Received: by 10.194.38.167 with HTTP; Thu, 12 Sep 2013 13:27:44 -0700 (PDT)
In-Reply-To: <FAF0B30B-0F54-43F6-9239-AC0CC64AC955@mu.org>
References: <CA+qNgxSVkSi88UC3gmfwigmP0UCO6dz+_Zxhf_=URK7p4c-Ghg@mail.gmail.com>
<CAFHCsPXJkxvJrhfbZt5T=Bm=ZS8-+E9xL1cY7b6UENHJ74YR5Q@mail.gmail.com>
<CA+qNgxT68eobU+G4AjKeU6wZb0xM_sktDdQ=jCcmYyzQR+asiw@mail.gmail.com>
<201309120824.52916.jhb@freebsd.org>
<FAF0B30B-0F54-43F6-9239-AC0CC64AC955@mu.org>
Date: Thu, 12 Sep 2013 16:27:44 -0400
Message-ID: <CA+qNgxQcXW92QEN22isBGWAR4omWOFb8MLVHPDjD8wtos4UosA@mail.gmail.com>
Subject: Re: Why do we need to acquire the current thread's lock before
context switching?
From: Dheeraj Kandula <dkandula@gmail.com>
To: Alfred Perlstein <bright@mu.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.14
Cc: Svatopluk Kraus <onwahe@gmail.com>,
"freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2013 20:27:47 -0000
Hey Alfred,
I can create a diff to add the comments to the file proc.h and
commit it if that works.
Dheeraj
On Thu, Sep 12, 2013 at 4:21 PM, Alfred Perlstein <bright@mu.org> wrote:
> Both these explanations are so great. Is there any way we can add this to
> proc.h or maybe document somewhere and then link to it from proc.h?
>
> Sent from my iPhone
>
> On Sep 12, 2013, at 5:24 AM, John Baldwin <jhb@freebsd.org> wrote:
>
> > On Thursday, September 12, 2013 7:16:20 am Dheeraj Kandula 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?
> >
> > It's less complicated than that. :) It is a mutex, but to expand on wh=
at
> > Svatopluk said with an example: take a thread that is asleep on a sleep
> > queue. td_lock points to the relevant SC_LOCK() for the sleep queue
> chain
> > in that case, so any other thread that wants to examine that thread's
> > state ends up locking the sleep queue while it examines that thread. I=
n
> > particular, the thread that is doing a wakeup() can resume all of the
> > sleeping threads for a wait channel by holding the one SC_LOCK() for th=
at
> > wait channel since that will be td_lock for all those threads.
> >
> > In general mutexes are only unlocked by the thread that locks them,
> > and the td_lock of the old thread is unlocked during sched_switch().
> > However, the old thread has to grab td_lock of the new thread during
> > sched_switch() and then hand it off to the new thread when it resumes.
> > This is why sched_throw() and sched_switch() in ULE directly assign
> > 'mtx_lock' of the run queue lock before calling cpu_throw() or
> > cpu_switch(). That gives the effect that the new thread resumes while
> > holding the lock pinted to by its td_lock.
> >
> >> 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 gian=
t
> >>> 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
> >wrote:
> >>>
> >>>> Thanks a lot Alfred for the clarification. So is the td_lock granula=
r
> 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 t=
he
> >>>> 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
> selected
> >>>>>> 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 a=
t
> any
> >>>>>> time runs only on one of the cores of a CPU. Hence when it is bein=
g
> >>>>>> 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 loc=
k.
> >>>> Isn't
> >>>>>> it? Am I missing something here? I don't see any contention for th=
e
> >>>> 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"
> >> _______________________________________________
> >> 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=
"
> >
> > --
> > John Baldwin
> > _______________________________________________
> > 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"
> >
>