Linux Device Driver Development Cookbook

Locking with the process context

It's good to understand how to avoid race conditions in case more than one process tries to get access to our driver, or how to put to sleep a reading process (we talk about reading here, but the same thing also holds true for writing) in case our driver has no data to supply. The former case will be presented here, while the latter will be presented in the next section.

If we take a look at how read() and write() system calls have been implemented in our chrdev driver, we can easily notice that, if more than one process tries to do a read() call or even if one process attempts a read() call and another tries a write() call, a race condition will occur. This is because the ESPRESSObin's CPU is a multiprocessor ...