The first point is pretty obvious; take a look at the pseudocode shown in the following screenshot:
Figure 12.5 – Pseudocode – a critical section within a (fictional) driver's read method; it's wrong as there's no locking
It's a similar situation to what we showed in Figures 12.1 and 12.3; it's just that here, we're showing the concurrency in terms of pseudocode. Clearly, from time t2 to time t3, the driver is working on some global shared writeable data, thus making this a critical section.
Now, visualize a system with, say, four CPU cores (an SMP system); two user space processes, P1 (running on, say, CPU 0) and P2 (running on, say, CPU 2), can concurrently open the device file and simultaneously issue a read(2) system call. Now, both processes will be concurrently executing the driver read "method", thus simultaneously working on shared writeable data...
