Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Readers and Writers

 
Mark Smyth
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello again,
I have decided to open a new RandomAccessFile object in each public method this is passed to the private helper methods. This way each record has its own local file handle and eliminates the need for synchronizing on a single RandomAccess objectble everytime we wish to perform an IO operation. That is a pretty long queue if there are 10 readers waiting unnescessarly for a file pointer to become available for example. Does the overhead of all these extra file connections cancel out the benefit?

The second point was is about reading while another thread is writing. Am I correct in assuming that a read on a record while a write is going on could be corrupted? For this I have implemented a version of the readers / writers solution. All readers wait on a semaphore until there are no threads writing or that wish to write (It is biased in favour of writers as they may have had to contend for record locks already ) A writer must wait until all readers are finished (But threads that wish to read must queue behind the writers). Then all writers can go through (They would all have a different record locks and so not interfere with each other). I already have it implemented but I was wondering if this extra effort is pointless for the assignment. It will have a certain performance impact to consider too.

Thanks in advance guys.
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Smyth:
Hello again,

Me, too. Hi again

The second point was is about reading while another thread is writing. Am I correct in assuming that a read on a record while a write is going on could be corrupted? For this I have implemented a version of the readers / writers solution. All readers wait on a semaphore until there are no threads writing or that wish to write (It is biased in favour of writers as they may have had to contend for record locks already ) A writer must wait until all readers are finished (But threads that wish to read must queue behind the writers). Then all writers can go through (They would all have a different record locks and so not interfere with each other). I already have it implemented but I was wondering if this extra effort is pointless for the assignment. It will have a certain performance impact to consider too.

This is same as doing record locking. That is you only want to do one thing, i.e. either read or write on a record. I too wanted to implement it at first, but its not required. There is always a chance that the record is changed once it is read and shown to client. What I meant is you read by locking the record, you unlock and then try to pass the result to client. If one thread which just read unlocks, and another thread acquires lock and writes to the record then the client is however seeing the "corrupted data". Instead to make life simpler, we just document that we are not locking while reading a record and ignore this issue. Atleast, that's what I am doing

Thanks in advance guys.
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Smyth:
Hello again,
I have decided to open a new RandomAccessFile object in each public method this is passed to the private helper methods. This way each record has its own local file handle and eliminates the need for synchronizing on a single RandomAccess objectble everytime we wish to perform an IO operation. That is a pretty long queue if there are 10 readers waiting unnescessarly for a file pointer to become available for example. Does the overhead of all these extra file connections cancel out the benefit?
Thanks in advance guys.

Mark, sounds reasonable.
 
Mark Smyth
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is always a chance that the record is changed once it is read and shown to client. What I meant is you read by locking the record, you unlock and then try to pass the result to client. If one thread which just read unlocks, and another thread acquires lock and writes to the record then the client is however seeing the "corrupted data". Instead to make life simpler, we just document that we are not locking while reading a record and ignore this issue.

Man is there anything that document can't do?
I think you are right since you cannot guarantee that the record will be valid by the time the client reacts to it it. No sense in throwing around synchronized code like confetti.
Just realized, the first part of the post was about taking out synchronized stuff and then a paragraph later I am trying to put more in, talk about a guy who knows what he wants! Guess the assignment makes one think a bit more than is healthy. Documentation it is then.
Thanks for your help.
[ March 05, 2004: Message edited by: Mark Smyth ]
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Happy to help
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic