ViewVC Help

View File | Revision Log | Show Annotations | Download File | Root Listing

root/jsr166/jsr166/src/main/java/util/concurrent/CyclicBarrier.java

Comparing jsr166/src/main/java/util/concurrent/CyclicBarrier.java (file contents):
Revision 1.6 by dl, Tue Jul 8 00:46:33 2003 UTC vs.
Revision 1.7 by dl, Tue Aug 5 22:50:28 2003 UTC

#	Line 86 | Line 86 | import java.util.concurrent.locks.*;
86		* and best strategy for sharing knowledge about failures among
87		* cooperating threads in the most common usage contexts of barriers.
88		*
89	–	* <h3>Implementation Considerations</h3>
90	–	* <p>This implementation has the property that interruptions among newly
91	–	* arriving threads can cause as-yet-unresumed threads from a previous
92	–	* barrier cycle to return out as broken. This transmits breakage as
93	–	* early as possible, but with the possible byproduct that only some
94	–	* threads returning out of a barrier will realize that it is newly
95	–	* broken. (Others will not realize this until a future cycle.)
96	–	*
97	–	*
98	–	*
89		* @since 1.5
90		* @spec JSR-166
91		* @revised $Date$
92		* @editor $Author$
93		* @see CountDownLatch
94		*
105	–	* @fixme Is the above property actually true in this implementation?
106	–	* @fixme Should we have a timeout version of await()?
95		* @author Doug Lea
96		*/
97		public class CyclicBarrier {
#	Line 148 | Line 136 | public class CyclicBarrier {
136		}
137
138		/**
139	<	* Main barrier code, covering the various pilicies.
139	>	* Main barrier code, covering the various policies.
140		*/
141		private int dowait(boolean timed, long nanos) throws InterruptedException, BrokenBarrierException, TimeoutException {
142		lock.lock();
#	Line 205 | Line 193 | public class CyclicBarrier {
193		throw new TimeoutException();
194		}
195
196	<	if (broken == generation)
196	>	if (broken == g)
197		throw new BrokenBarrierException();
198
199		}

Diff Legend

–	Removed lines
+	Added lines
<	Changed lines
>	Changed lines