As mentioned explicitly in the book, there are times when we deliberately went above and beyond what was absolutely required for the project - mainly so that our sample assignment could not be used as a real assignment. There is a little bit of that in the read lock usage.
As you noted, multiple threads can own a read lock simultaneously. However only one thread can own a write lock at any given time, and no thread can own a write lock while any thread owns a read lock.
How this affects you depends on what your atomic
unit of work is. As a minimalistic block, you could have (pseudo-code):
This will certainly work, and the atomic operation (the reading from file) is so small that the difference between using read/write locks versus using one single mutex for file access is not worth worrying about.
However there is a good argument for making the atomic operation larger, making our potential code:
This can make the code easier to read as now the locking and unlocking are the first and last items in the method. This would match up with the logic for writing a record, where you would probably want the entire logic encapsulated in a logical lock.
Since this later version of the code has a lock for a longer period of time, it makes sense to use the read-locks, so that multiple threads can read the same record simultaneously - they can all be doing the initialization logic and/or the conversion logic without worrying that another thread may be writing to that record - as mentioned earlier, as long as there is one read lock on a record, there cannot be a write lock on that record.
Does that make sense?