From owner-freebsd-arch@FreeBSD.ORG Thu Sep 12 17:57:15 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 7EF962A5 for ; Thu, 12 Sep 2013 17:57:15 +0000 (UTC) (envelope-from dkandula@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A4B024BC for ; Thu, 12 Sep 2013 17:57:14 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hm2so163139wib.0 for ; Thu, 12 Sep 2013 10:57:13 -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=SvcT7/+VVMGrttiOSmJ0T0tw6L8NUw6RzugmZv6xKM8=; b=U3kNvjX54hvmRFVGT3GnMkm4l4FC2PsLOAyCGSQs/Q8MpVMx6uOlhS7YN73Xm1g430 2Qmiey8e8UqYdanPuQUC3C8Yct/Dfs7rcN9hRVPkH/g+w8WWDKxc41h7IP/ozQ76KujH pRSp4Ehwy1MNG+oWYWFJ9vPHd4o/Yx6UiZ1S/6PnpLMYiOFN4LWDXRYapfM6jj4jwMWi pbe9EiZ3C+v6uD1ZEUUDs6Fduq81iTmwnrU3jT0V9nKMCUZquXfQqPCAqAN8fAnUQYtB uwxM1nezBQigzU/1rJPWkh90VP4o95ZMfAgnmWxaKxpitVdOuGJgGoupsVoOjbkPzTOH ySMA== MIME-Version: 1.0 X-Received: by 10.180.188.49 with SMTP id fx17mr6943418wic.49.1379008633537; Thu, 12 Sep 2013 10:57:13 -0700 (PDT) Received: by 10.194.38.167 with HTTP; Thu, 12 Sep 2013 10:57:13 -0700 (PDT) In-Reply-To: References: <523168EE.4070508@mu.org> Date: Thu, 12 Sep 2013 13:57:13 -0400 Message-ID: Subject: Re: Why do we need to acquire the current thread's lock before context switching? From: Dheeraj Kandula To: Svatopluk Kraus 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 17:57:15 -0000 Great. Now I understand it better. Thanks for the reply Svatopluk. Dheeraj On Thu, Sep 12, 2013 at 8:30 AM, Svatopluk Kraus 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 lea= st > during task switch. > > Svatopluk Kraus > > On Thu, Sep 12, 2013 at 1:16 PM, Dheeraj Kandula wrot= e: > >> 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 mu= st >> 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 queu= e >>> 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. An= d 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 suggeste= d >>>> but >>>> just wanted to have a deeper understanding before I go about hunting i= n >>>> 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 >>>> 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= " >>>> >>> >>> >> >