98 * separate lock (the AWT lock) that only needs to be acquired when
99 * we are about to flush the queue (using native windowing system
100 * operations). In practice it has been difficult to enforce the
101 * correct lock ordering; sometimes AWT will have already acquired
102 * the AWT lock before grabbing the RQ lock (see 6253009), while the
103 * expected order should be RQ lock and then AWT lock. Due to this
104 * issue, using two separate locks is prone to deadlocks. Therefore,
105 * to solve this issue we have decided to eliminate the separate RQ
106 * lock and instead just acquire the AWT lock here. (Someday it might
107 * be nice to go back to the old two-lock system, but that would
108 * require potentially risky changes to AWT to ensure that it never
109 * acquires the AWT lock before calling into 2D code that wants to
110 * acquire the RQ lock.)
111 */
112 SunToolkit.awtLock();
113 }
114
115 /**
116 * Attempts to lock the queue. If successful, this method returns true,
117 * indicating that the caller is responsible for calling
118 * <code>unlock</code>; otherwise this method returns false.
119 */
120 public final boolean tryLock() {
121 return SunToolkit.awtTryLock();
122 }
123
124 /**
125 * Unlocks the queue.
126 */
127 public final void unlock() {
128 SunToolkit.awtUnlock();
129 }
130
131 /**
132 * Adds the given Object to the set of hard references, which will
133 * prevent that Object from being disposed until the queue has been
134 * flushed completely. This is useful in cases where some enqueued
135 * data could become invalid if the reference Object were garbage
136 * collected before the queue could be processed. (For example, keeping
137 * a hard reference to a FontStrike will prevent any enqueued glyph
138 * images associated with that strike from becoming invalid before the
|
98 * separate lock (the AWT lock) that only needs to be acquired when
99 * we are about to flush the queue (using native windowing system
100 * operations). In practice it has been difficult to enforce the
101 * correct lock ordering; sometimes AWT will have already acquired
102 * the AWT lock before grabbing the RQ lock (see 6253009), while the
103 * expected order should be RQ lock and then AWT lock. Due to this
104 * issue, using two separate locks is prone to deadlocks. Therefore,
105 * to solve this issue we have decided to eliminate the separate RQ
106 * lock and instead just acquire the AWT lock here. (Someday it might
107 * be nice to go back to the old two-lock system, but that would
108 * require potentially risky changes to AWT to ensure that it never
109 * acquires the AWT lock before calling into 2D code that wants to
110 * acquire the RQ lock.)
111 */
112 SunToolkit.awtLock();
113 }
114
115 /**
116 * Attempts to lock the queue. If successful, this method returns true,
117 * indicating that the caller is responsible for calling
118 * {@code unlock}; otherwise this method returns false.
119 */
120 public final boolean tryLock() {
121 return SunToolkit.awtTryLock();
122 }
123
124 /**
125 * Unlocks the queue.
126 */
127 public final void unlock() {
128 SunToolkit.awtUnlock();
129 }
130
131 /**
132 * Adds the given Object to the set of hard references, which will
133 * prevent that Object from being disposed until the queue has been
134 * flushed completely. This is useful in cases where some enqueued
135 * data could become invalid if the reference Object were garbage
136 * collected before the queue could be processed. (For example, keeping
137 * a hard reference to a FontStrike will prevent any enqueued glyph
138 * images associated with that strike from becoming invalid before the
|