On Thursday 17 March 2011, Waldemar.Rymarkiewicz@xxxxxxxxx wrote: > >> >Note that the microread_is_busy() logic does not protect you from > >> >having multiple concurrent readers, because multiple threads may > >> >share a single file descriptor. > >> > >> It's just used to ensure that only one reader can open the device. > >> It's called only in open callback. > >> The mutex actually secures concurrent read operations. > > > >So if having multiple readers is safe (though possibly not > >meaningful), I guess you don't really need the > >microread_is_busy() logic. > > > >I suppose it doesn't hurt either, it just seems a bit > >pointless when it does the right thing most of the time, but > >not always. > > > > Could you give me an example when the microread_is_busy() logic does > not do what it's intended to do. I don't really get your point here. > An application can open the device, and then do a pthread_create() or a fork(). In either case, you have two concurrent threads that have access to the file pointer and can read from it concurrently, which is inherently racy regarding which of the processes gets the data. This is not very different from opening the file descriptor in multiple processes, which you prevent using your logic. You can of course argue that you try your best to prevent the race. Traditionally, e.g. on serial ports and the like, we don't do this but instead rely on user space synchronizing the access. What you have to make sure of course is that multiple threads calling read on the same file can never bring the kernel driver into an invalid state. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
