com.sun.jini.fiddler
Class FiddlerImpl.SnapshotThread
java.lang.Object
java.lang.Thread
com.sun.jini.thread.InterruptedStatusThread
com.sun.jini.fiddler.FiddlerImpl.SnapshotThread
- All Implemented Interfaces:
- Runnable
- Enclosing class:
- FiddlerImpl
private class FiddlerImpl.SnapshotThread
- extends InterruptedStatusThread
Snapshot-taking thread.
A snapshot is taken when -- after writing a new record to the
log file -- it is determined that the size of the log file has
exceeded a certain threshold. The code which adds the new record
to the log file and which, in turn, decides that a snapshot
must be taken is "wrapped" in a writer mutex. That is, synchronization
of processing is achieved in this service through a "reader/writer"
mutex construct. This construct allows only one writer at any one
time; but allows an unlimited number of simultaneous readers as
long as no writer has locked the mutex. During steady-state, it is
anticipated that far more "read actions" will occur (e.g. discovery
events being sent) than "write actions" (e.g. modifying the managed
sets). Since the process of taking a snapshot can be time-consuming,
if the whole snapshot-taking process occupies that single writer
mutex, then a significant number of read actions will be un-necessarily
blocked; possibly resulting in an unacceptable degradation in
response time.
It is for the above reason that the process of taking a snapshot is
performed in a separate thread. The thread waits on the monitor
belonging to the snapshotThreadSyncObj instance until it is notified
(or "signalled") that a snapshot must be taken. The notification
is sent by another thread, created by this service, which determines
when the conditions are right for a snapshot. The notification takes
the form of an interrupt indicating that the snapshot monitor is
available. Although the interrupt is sent while the writer mutex is
locked, the act of sending the notification is less time-consuming
than the act of taking the snapshot itself. When the thread receives
a notification, it awakens and requests a lock on the reader mutex
(this is all done in the readerWait() method). Because a reader -- not
a writer -- mutex is locked, read-only processes still have access
to the system state, so discovery events can be sent and the service's
state can be queried; but the reader mutex prevents changes to the
state while the snapshot is in progress.
Note that the current snapshot is guaranteed to complete before the
next snapshot request is received. This is because even though
the act of taking a snapshot can be viewed as a writer process,
the fact that the next snapshot notification will be wrapped in a
writer mutex, combined with the fact that a writer mutex can not
be locked while a reader mutex is locked, allows the snapshot to
be treated as a reader process.
Method Summary |
void |
run()
|
Methods inherited from class java.lang.Thread |
activeCount, checkAccess, clone, countStackFrames, currentThread, destroy, dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, stop, suspend, toString, yield |
FiddlerImpl.SnapshotThread
public FiddlerImpl.SnapshotThread()
- Create a daemon thread
run
public void run()
- Specified by:
run
in interface Runnable
- Overrides:
run
in class Thread
Copyright 2007-2010, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.