<snip> > > I generally use spinlocks for protecting my shared data. Reasonable, but IMHO a mutex should be used to protect a hardware device. I know James is not you working with real hardware, but since he's trying to learn good habits it seems more logical to protect his buffer as if it were real hardware. The reason I dislike spin locks for real hardware is if the hardware is slow to respond for whatever reason. Let's assume you have a fast device that should complete the transaction in microseconds, so you decide to protect it with a spin lock. It seems reasonable to spin for microseconds waiting for another process to release the lock, but then consider the malfunction situation where the device never completes the transaction. Waiting on a spin lock basically forever is going to drastically affect the performance of the machine. And if 9 additional tasks find themselves spinning on the one spin lock because of a hardware failure, you basically have a dead machine. A mutex would not have the same negative impact. Obviously the dead device would be INOP, but the rest of the system would still work fine. Thus I would avoid spin locks when protecting devices, even conceptual ones. It leads to what I consider bad practice when you move to real hardware. fyi: I have no idea if there is a linux kernel developers opinion about this. It is just my opinion. > You can use > the spinlocks in WRITE method of your device driver code for > protecting data among 10 processes. You can initialize the spinlock > with spin_lock_init API and lock it using spin_lock() and unlock it > using spin_unlock() API. There are variants of spinlocks. As suggested > by Greg, you can go through the 5th Chanpter in LDD3. Greg -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
