From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 22 22:26:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF8A416A49E for ; Fri, 22 Dec 2006 22:26:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4191013C41A for ; Fri, 22 Dec 2006 22:25:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so3328497nfc for ; Fri, 22 Dec 2006 14:25:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UEUocztrfVem/rDRNkj5nOarHdtNsn+k/8nD8GoB9xDxmOaEllyj1lpsRnsrZnBbtCJhoGXUKgkUKmlHpK9HjHJkEvMBnc8iKA1ZsmYepkfhlYZeh/0upQWshL/WkvOLDEg9Vz4jSvVSccCrslm8YF0Q7A6yDAVw1OOEkKRFn4M= Received: by 10.82.120.14 with SMTP id s14mr89418buc.1166826353139; Fri, 22 Dec 2006 14:25:53 -0800 (PST) Received: by 10.82.178.4 with HTTP; Fri, 22 Dec 2006 14:25:53 -0800 (PST) Message-ID: <3bbf2fe10612221425j62374c46q538ca2e256f7efc2@mail.gmail.com> Date: Fri, 22 Dec 2006 23:25:53 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: <20061222134113.T65423@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061220041843.GA10511@dwpc.dwlabs.ca> <3bbf2fe10612200414j4c1c01ecr7b37e956b70b01fa@mail.gmail.com> <458A249D.3030502@FreeBSD.org> <3bbf2fe10612210558m66795673kd352a385a98f6e2b@mail.gmail.com> <20061222134113.T65423@fledge.watson.org> X-Google-Sender-Auth: af44d0f2b0dbb143 Cc: freebsd-hackers@freebsd.org, ssouhlal@freebsd.org, duane@dwlabs.ca Subject: Re: Locking fundamentals X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2006 22:26:00 -0000 2006/12/22, Robert Watson : > On Thu, 21 Dec 2006, Attilio Rao wrote: > > >> I disagree. There are many uses of atomic operations in the kernel that are > >> not for locks or refcounts. It's a bad idea to use locks if you can achieve > >> the same thing locklessly, with atomic operations. > > > > I can agree with you about this but atomic instructions/memory barriers > > should be used very carefully (and if you know what you are going to do). It > > is very simple to write down a wrong semantic using them. > > Agreed here also -- it is easy to use atomic operations incorrectly, > especially with decreasing memory consistency properties. Simple statistics > are about the only place they're safe to use without very careful thinking. > There are some nice examples in the updated version of Andrew Birrell's > threading paper of just how easy it is to shoot feet using atomic operations. > > >> I would personally also add "critical sections" > >> (critical_enter()/critical_exit()) at level I. They can be used instead of > >> locks when you know your data will only be accessed on one CPU, and you > >> only need to protect it from (non-FAST) interrupt handlers. > > > > From this point of view, we would also add sched_pin()/sched_unpin() which > > are used in order to avoid thread migration between CPUs (particulary > > helpfull in the case we have to access safely to some per-CPU datas). > > However, probabilly one of the most important usage we do of > > critical_section is in the spin mutex implementation (which linked to > > interrupt disabling would avoid deadlock in spin mutex code). > > sched_bind(), sched_pin(), and friends are also potentially dangerous unless > used very carefully: they work alright if the thread is dedicated to a single > purpose and written entirely with that synchronization model in mind, or if > the period of pinning is brief (and it doesn't matter what CPU it's on). > However, as soon as you have multiple code modules interacting with each > other, you have to be very careful about the thread moving around when not > expected by calling code, starvation issues, etc. Pinning a thread briefly > using a critical section to access data on the whatever the current CPU may be > is a fine (and good) strategy, but service components of the kernel should not > employ extended pinning unless it's been carefully thought out, especially > with regard to other components it may call, or that may call it. In that > sense, of course, it's not different than locking, only we have a weaker > assertion/consistency verification system. It's frequently the interactions > between components/subsystems that make synchronization most difficult. ...and please note that it is worthwhile just for preemptive kernels. Attilio -- Peace can only be achieved by understanding - A. Einstein