< prev index next >

src/java.desktop/share/classes/sun/java2d/StateTrackable.java

Print this page




 112  * This would require synchronized blocks around some potentially large
 113  * bodies of code which would impact the multi-threaded scalability of
 114  * the implementation.
 115  * Further, if data is to be coordinated or transferred between two
 116  * trackable objects then both would need to be synchronized raising
 117  * the possibility of deadlock unless some strict rules of priority
 118  * for the locking of the objects were established and followed
 119  * religiously.
 120  * Either or both of these drawbacks makes such an implementation
 121  * infeasible.
 122  * <p>
 123  * A less conservative approach would be to change the state of the
 124  * trackable object to DYNAMIC during all modifications of the data
 125  * and then to change it back to STABLE after those modifications
 126  * are complete.
 127  * While this state transition more accurately reflects the temporary
 128  * loss of tracking during the modification phase, in reality the
 129  * time period of the modifications would be small in most cases
 130  * and the 2 changes of state would each require synchronization.
 131  * <p>
 132  * In comparison the act of setting the <code>curTracker</code>
 133  * reference to null in the usage pattern above effectively invalidates
 134  * all outstanding <code>Tracker</code> objects as soon as possible
 135  * after the change to the data and requires very little code and no
 136  * synchronization to implement.
 137  * <p>
 138  * In the end it is up to the implementor of a StateTrackable object
 139  * how fine the granularity of State updates should be managed based
 140  * on the frequency and atomicity of the modifications and the
 141  * consequences of returning an inaccurate State for a particularly
 142  * small window of opportunity.
 143  * Most implementations are likely to follow the liberal, but efficient
 144  * guidelines found in the usage pattern proposed above.
 145  *
 146  * @since 1.7
 147  */
 148 public interface StateTrackable {
 149     /**
 150      * An enumeration describing the current state of a trackable
 151      * object.
 152      * These values describe how often the complex data contained
 153      * in a trackable object can be changed and whether or not it
 154      * makes sense to try to track the data in its current state.




 112  * This would require synchronized blocks around some potentially large
 113  * bodies of code which would impact the multi-threaded scalability of
 114  * the implementation.
 115  * Further, if data is to be coordinated or transferred between two
 116  * trackable objects then both would need to be synchronized raising
 117  * the possibility of deadlock unless some strict rules of priority
 118  * for the locking of the objects were established and followed
 119  * religiously.
 120  * Either or both of these drawbacks makes such an implementation
 121  * infeasible.
 122  * <p>
 123  * A less conservative approach would be to change the state of the
 124  * trackable object to DYNAMIC during all modifications of the data
 125  * and then to change it back to STABLE after those modifications
 126  * are complete.
 127  * While this state transition more accurately reflects the temporary
 128  * loss of tracking during the modification phase, in reality the
 129  * time period of the modifications would be small in most cases
 130  * and the 2 changes of state would each require synchronization.
 131  * <p>
 132  * In comparison the act of setting the {@code curTracker}
 133  * reference to null in the usage pattern above effectively invalidates
 134  * all outstanding {@code Tracker} objects as soon as possible
 135  * after the change to the data and requires very little code and no
 136  * synchronization to implement.
 137  * <p>
 138  * In the end it is up to the implementor of a StateTrackable object
 139  * how fine the granularity of State updates should be managed based
 140  * on the frequency and atomicity of the modifications and the
 141  * consequences of returning an inaccurate State for a particularly
 142  * small window of opportunity.
 143  * Most implementations are likely to follow the liberal, but efficient
 144  * guidelines found in the usage pattern proposed above.
 145  *
 146  * @since 1.7
 147  */
 148 public interface StateTrackable {
 149     /**
 150      * An enumeration describing the current state of a trackable
 151      * object.
 152      * These values describe how often the complex data contained
 153      * in a trackable object can be changed and whether or not it
 154      * makes sense to try to track the data in its current state.


< prev index next >