From owner-freebsd-arch@FreeBSD.ORG Thu Sep 12 11:04:21 2013 Return-Path: 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 7A2A7855 for ; Thu, 12 Sep 2013 11:04:21 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 389CF28E7 for ; Thu, 12 Sep 2013 11:04:21 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id n4so3749944qcx.13 for ; Thu, 12 Sep 2013 04:04:20 -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=DOg9Prqu3CwrLJsBmsB/DhbumeXkP2+nTDLRAJyLtWk=; b=0b8EYGH16T/t8YIsn4a4h1YGBuIHPVQ6J6BMxug73pOi5OjdKMK9WtPVYPV2f+mHBo FoEe6iNMmCwg54pdfIg5Ir+R1Z5EgbrkJJv5lyvF8hOLfXbM6eV2UQ8Fi1V4a8l0Vcsc xqexeP0l24s9h+EhINNWDTOSoP8+CS2SstMJc5BACizYxCqiaRHVZKASvHGowKmq0X9A AQlpEBq1uNPX6TfiUyxVcW+YxnkhGnyg637s8bmh+WgPZmkKwQlb9iwBQ+pTjUPCdgtS 8QwV0Uhseng9og8TubmqwK+3QBlOb3KRa08gU8xJ8y9d1TzehX2pMZ6BHUJmso3gY7og FU6A== MIME-Version: 1.0 X-Received: by 10.49.130.162 with SMTP id of2mr12526202qeb.37.1378983860268; Thu, 12 Sep 2013 04:04:20 -0700 (PDT) Received: by 10.140.90.7 with HTTP; Thu, 12 Sep 2013 04:04:20 -0700 (PDT) In-Reply-To: References: <523168EE.4070508@mu.org> Date: Thu, 12 Sep 2013 13:04:20 +0200 Message-ID: Subject: Re: Why do we need to acquire the current thread's lock before context switching? From: Svatopluk Kraus To: Dheeraj Kandula Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alfred Perlstein , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 11:04:21 -0000 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 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 b= ut > just wanted to have a deeper understanding before I go about hunting in t= he > code. > > Dheeraj > > > On Thu, Sep 12, 2013 at 3:10 AM, Alfred Perlstein wrote: > > > On 9/11/13 2:39 PM, Dheeraj Kandula wrote: > > > >> Hey All, > >> > >> When the current thread is being context switched with a newly selecte= d > >> thread, why is the current thread's lock acquired before context switc= h > =96 > >> mi_switch() is invoked after thread_lock(td) is called. A thread at an= y > >> 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 run= q > or > >> the idle runq with the lock still held or it is added to the sleep que= ue > >> 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" >