From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 15:18:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30EBB106564A for ; Wed, 23 Feb 2011 15:18:24 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C78018FC0A for ; Wed, 23 Feb 2011 15:18:23 +0000 (UTC) Received: by qyk27 with SMTP id 27so2699477qyk.13 for ; Wed, 23 Feb 2011 07:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S3e0J/hprUuV1zQAfV/5xSYEsb1r8RJfkSrt/AGh6ZE=; b=w2cJwT1iFmPrp/ZvHjPQNe+rYuQxZYOiNtka3KSp+w64StXxkpU6CkLdPk9CsVkBH1 e3RcS99+rH2cIrVph40r+HYHGGKNQbGjucbYZGZMyi3v5orbCzJKr5ixvsqtpEbNINqA KmkFXTMwPHUdwJKdkzJek57pcaMTZQJHcH3vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DEstpdkThB3xd7VCDy8ZH1GgCdJ+vTyml/PfUTU1lxiZ7sMVB1oNpMLy40pZQFNfWb r1Ekq0bdq7PzRAjhyYwBFXbyCgxxiaYvt10iUQKmBQd/te2zaENFKi8c5uZcDxwusDx7 /qc8MdOcQDJ4R90hN9HOCjepo6bFOEacG0r/A= MIME-Version: 1.0 Received: by 10.224.176.67 with SMTP id bd3mr3540777qab.110.1298474302851; Wed, 23 Feb 2011 07:18:22 -0800 (PST) Received: by 10.224.73.206 with HTTP; Wed, 23 Feb 2011 07:18:22 -0800 (PST) In-Reply-To: <201102220937.53075.jhb@freebsd.org> References: <201102220937.53075.jhb@freebsd.org> Date: Wed, 23 Feb 2011 16:18:22 +0100 Message-ID: From: Svatopluk Kraus To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: ichsmb - correct locking strategy? 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: Wed, 23 Feb 2011 15:18:24 -0000 On Tue, Feb 22, 2011 at 3:37 PM, John Baldwin wrote: > On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote: >> Hi, >> >> =A0 I try to figure out locking strategy in FreeBSD and found 'ichsmb' >> device. There is a mutex which protects smb bus (ichsmb device). For >> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is >> locked and a command is written to bus, then unbounded (but with >> timeout) sleep is done (mutex is unlocked during sleep). After sleep a >> word is read from bus and the mutex is unlocked. >> >> =A0 1. If an use of the device IS NOT serialized by layers around then >> more calls to this function (or others) can be started or even done >> before the first one is finished. The mutex don't protect sms bus. >> >> =A0 2. If an use of the device IS serialized by layers around then the >> mutex is useless. >> >> =A0 Moreover, I don't mension interrupt routine which uses the mutex and >> smb bus too. >> >> =A0 Am I right? Or did I miss something? > > Hmm, the mutex could be useful if you have an smb controller with an inte= rrupt > handler (I think ichsmb or maybe intpm can support an interrupt handler) = to > prevent concurrent access to device registers. =A0That is the purpose of = the > mutex at least. =A0There is a separate locking layer in smbus itself in (= see > smbus_request_bus(), etc.). > > -- > John Baldwin > I see. So, multiple accesses to bus are protected by upper smbus layer itself. And the mutex encloses each single access in respect of interrupt. I.e., an interrupt can be assigned to a command (bus is either command processing or idle) and a wait to command result can be done atomically (no wakeup is missed). Am I right? BTW, a mutex priority propagation isn't too much exploited here. Maybe, it will be better for me to not take this feature into account when thinking about locking strategy and just take a mutex in most cases as a low level locking primitive which is indeed. Well, it seems that things become more clear.