• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Held Locks While Potentially Blocking on I/O

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
My threading studies suggest that one should not carry out an activity
which might potentially block when you hold a lock.
Thus:

in the above snippet, if the thread mutating the file record blocks for any
significant amount of time, I am, technically, breaking this design
rule: holding a lock while entering into an operation which may
block.
Question:
Is it safe to not worry about this? That is, I will never attempt
to interrupt the thread that is mutating a record within my
RandomAccessFile. The mutation operation will always be
expected to work, and if it fails, I will take no special action:
if it fails, the database is considered not to be functioning
properly.
Thanks,
Javini Javono
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
Are you talking about activities performed while owning a mutex lock, or activities performed while owning a logical lock?
General theory says that you should try to limit the amount of processing done while owning a mutex, as this can block other threads.
But your sample code seems to be using logical locking, in which case, what is the problem you see?
Regards, Andrew
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
My studies had not enlightened me as to a rule difference between logical locks
(i.e., the LockManager) and a mutex (i.e., Java's synchronized key word).
When the RandomAccessFile is either read or written, that tiny method
within MicroData is synchronized.
And, when the record is mutated, I hold both locks:
1. lockManager's lock for a given record to be mutated,
2. A mutex on MicroData because all the methods are synchronized, i.e.,

Thus, any blocking which occurs, blocks everybody, since reads and updates to
the RandomAccessFile must be synchronized so that the file pointer does not
get confused. And, besides a minor blocking, if there is a major blocking of
any kind, the complete database gets blocked.
So, should I document this restriction, saying I'm aware of it, and if any read or
write to the file blocks for any significant amount of time or forever, the application
fails; or, should I build special code to interrupt a thread I send to a method of
MicroData, which, I played around with a little to day, and as a rough draft, might
look like this (though, of course, using standard I/O, I'd probably need to close the
file and open it again, and a whole bunch of other stuff which seems a little out of scoope):

In short, I see your points:
1. if I only hold a logical lock, which only locks 1 record, then I can, when
needed, take more time, such as to perform an expensive, time consuming
process (if I had to hold the lock while doing this).
2. But, if I hold a mutex via Java's synchronized keyword, you potentially
lose concurrency, so you need to synchronize, end the operation as quickly
as possible, and leave the synchronized block.
But, my question is: do I break the rules if I simply say: if this read or
write operation does not return from MicroData, then the database is
broken, the database remains forever locked, the application fails and
needs to be restarted.
Thanks,
Javini Javono
[ February 20, 2004: Message edited by: Javini Javono ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
But, my question is: do I break the rules if I simply say: if this read or
write operation does not return from MicroData, then the database is
broken, the database remains forever locked, the application fails and
needs to be restarted.

What rule do you think you are breaking?
You are right in that if your write operation does not return, then all other threads will block either there or in any other file access method. In which case your application would hang. But the write method should be very simple: just a seek and a write. So there should be no reason for it to fail to return unless there was a problem with the underlying storage system, in which case you have serious problems anyway.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic