• Post Reply Bookmark Topic Watch Topic
  • New Topic

ReadWriteLocks and Disk Access  RSS feed

 
Timothy Frey
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey guys. I'm working on the SCJD assignment but I felt that this was the proper forum because the question has more to do with threading than the exam itself.

I'm working on the Data Access component for the assignment. For those not familiar with the exam, all the data is stored in a single file. This data access layer can read and write records from this file. However, because multiple threads may want to do operations at the same time, this stuff needs to be thread safe.

One study guide I'm using, "SCJD Exam with J2SE5" (Monkhouse and Camerlengo), has suggested the following idea for making the data access layer thread safe:

- A Map is used to map record numbers to their locations in the data file.
- A ReadWriteLock is used to control access to that Map

Their idea is that multiple threads can read from that map at the same time, but one and only one should be allowed to write to it. Sounds good, until we get to the part about disk access. Remember, this map stores the location of the record (i.e. where to move the file pointer).

In their "readRecord" method, they attain a read lock on the map via the ReadWriteLock but then proceed to synchronize on the RandomAccessFile used for the data file. Obviously this is necessary, you don't want to move the file pointer to one location and then have another thread swoop in and move it before you get to read anything.

So, what's the point of the ReadWriteLock here? Even if you just want to read a record, you still need to synchronize on the file anyway because you're moving the file pointer around. If the map contained the data itself I could understand, but because you basically need a write lock to do any kind of operations, should I just abandon the whole ReadWriteLock thing and just stick to standard synchronization?

Thanks!
 
Henry Wong
author
Sheriff
Posts: 22853
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, what's the point of the ReadWriteLock here? Even if you just want to read a record, you still need to synchronize on the file anyway because you're moving the file pointer around. If the map contained the data itself I could understand, but because you basically need a write lock to do any kind of operations, should I just abandon the whole ReadWriteLock thing and just stick to standard synchronization?


If the bulk of your code, under the reader-writer lock context, also needs this other lock, then there may be little reason to have such a lock. However, if your code does other things that can be done in parallel, or can also write to another file, which uses a different file lock, then it may be worth it to keep it.

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!