From owner-freebsd-arch@FreeBSD.ORG Thu Sep 12 07:10:49 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B110CD16 for ; Thu, 12 Sep 2013 07:10:49 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA63259C for ; Thu, 12 Sep 2013 07:10:49 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 7BC741A3D68; Thu, 12 Sep 2013 00:10:39 -0700 (PDT) Message-ID: <523168EE.4070508@mu.org> Date: Thu, 12 Sep 2013 00:10:38 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dheeraj Kandula Subject: Re: Why do we need to acquire the current thread's lock before context switching? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 07:10:49 -0000 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