On Tue, Feb 22, 2011 at 3:37 PM, John Baldwin <j...@freebsd.org> wrote: > On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote: >> Hi, >> >> 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. >> >> 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. >> >> 2. If an use of the device IS serialized by layers around then the >> mutex is useless. >> >> Moreover, I don't mension interrupt routine which uses the mutex and >> smb bus too. >> >> Am I right? Or did I miss something? > > Hmm, the mutex could be useful if you have an smb controller with an interrupt > handler (I think ichsmb or maybe intpm can support an interrupt handler) to > prevent concurrent access to device registers. That is the purpose of the > mutex at least. There 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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"