Date: Wed, 23 Feb 2011 16:18:22 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: ichsmb - correct locking strategy? Message-ID: <AANLkTikCzBHUkg3%2B3pzaiOh2JCz9zNSgfPmXkYbzYJV-@mail.gmail.com> In-Reply-To: <201102220937.53075.jhb@freebsd.org> References: <AANLkTinv8EkNqvQaNWpbW_q8J8kqSiJuLSb3j5S842a=@mail.gmail.com> <201102220937.53075.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 22, 2011 at 3:37 PM, John Baldwin <jhb@freebsd.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikCzBHUkg3%2B3pzaiOh2JCz9zNSgfPmXkYbzYJV->