These are 2 ways to look at the basic mutex use case —
DD) you can use a mutex to serialize access to a piece of shared mutable data
CC) you can use a mutex to serialize passage through a code path — the so-called critical section
In the kernel, CC (not DD) is the main concern.
Many people intuitively cling on to the intuitive DD view and visualize the runtime using a mutex to regulate multiple threads’ access to shared Data, as if the mutex is a locker. However, I find CC a more realistic/accurate view.
DD is the “logical” view whereas CC is the physical view.
DD is achieved through CC.
The more low-level you go, the more you take the physical view and speak in terms of critical sections.
DD is more object oriented. For non-OO languages like C, DD is not as natural as in OO language. If a data item is passed by pointer, then any function running on any thread can modify it. It’s not enough to use a mutex on 99% of those functions and have one function access it directly.
In OO languages, that data item would Always be a private field, automatically restricting access to very few methods of the class. Now we understand why encapsulation is essential to threading.
In non-OO languages, it’s less natural to associate a mutex with a piece of data. If the shared data is passed by pointer, then the mutex must also be passed by pointer. The mutex-pointer must accompany the data-pointer.