NX: Held Locks While Potentially Blocking on I/O

[Javini Javono]

Hi,
My threading studies suggest that one should not carry out an activity
which might potentially block when you hold a lock.
Thus:

lockManager.lock(100);  //Lock record 100.
data.mutateRecord(100, recordData);
lockManager.unlock(100);

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]

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]

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.,

public class MicroData ... {
   public synchronized void mutateRecord(String recordValue, int recordNumber) ... {
      write the recordValue string to the recordNumber within the RandomAccessFile;
   }
}

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):

current thread has logical lock on record 100;
current thread starts newThread;
newThread will use MicroData to read or mutate record 100 (and during this
   operation, the complete database will be locked down by necessity);
newThread.join(waitTime);  //current thread waits a certain amount of time.
if (newThread.isAlive()) {
   //newThread is still reading or writing, darn it!
   newThread.interrupt();
   //And a whole host of other operations to keep the application working
   //properly.
} else {
   //Have returned from operation, and because newThread
   //is dead, the record read or update operation completed.
   //So, everything okay.
}

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]

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