From owner-freebsd-arch@FreeBSD.ORG Thu Sep 12 12:30:43 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 19CA63BC for ; Thu, 12 Sep 2013 12:30:43 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCD292F38 for ; Thu, 12 Sep 2013 12:30:42 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id r5so6250092qcx.9 for ; Thu, 12 Sep 2013 05:30:41 -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=gh3J7VsSoiUr1ZUhSY2F6hQ3146ws1ym5WYPlOgfMYo=; b=z+Ee2fvBPBCIqRaxlmwcK0IaN5Z85RBOWvBYK4VEqfoohNjQ5OfTRWAdkgie7KRlXo Nc1sU8p5aJVnhjVYC038NwUY6PEUJ2cDY237s0rTNoCVK/7q3nn/k1DlUyjxiYcuO/F0 ghIZflDrbiNjNWh6GWfv8hGpcC6xN+JZkhIyxHl7k2I9ADweuhhedDh7xu+KYQXNqLK/ O3fNF4629rDqJk6LgNvwgc2TPqq6+48xmwWSq/Ei0rSDVr6kaPUmWEGVZGaehroGaxo3 jD3vbADqRFQbPSmK4VcPZ3Y661DzKEgELQuhX2q489fmf9FDjBhzjMyOC3+s070olYgz u+BA== MIME-Version: 1.0 X-Received: by 10.49.42.101 with SMTP id n5mr12889716qel.31.1378989041778; Thu, 12 Sep 2013 05:30:41 -0700 (PDT) Received: by 10.140.90.7 with HTTP; Thu, 12 Sep 2013 05:30:41 -0700 (PDT) In-Reply-To: References: <523168EE.4070508@mu.org> Date: Thu, 12 Sep 2013 14:30:41 +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 12:30:43 -0000 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 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 mus= t > unlock it unlike a binary semaphore. Isn't it? > > Dheeraj > > > On Thu, Sep 12, 2013 at 7:04 AM, Svatopluk Kraus 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 w= rote: >> >>> 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 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 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 protec= t >>> 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" >>> >> >> >