CyclicBarrier behaviour incorrect if interruption occurs during barrier "trip"

The CyclicBarrier specification states that it uses a "fast-fail all or none breakage model for failed synchronization attempts" (i.e attempts that are interrupted or timed-out). The current behaviour does not meet this specification. If the last thread needed at the barrier arrives and commences to "trip" the barrier, and a waiting thread is then interrupted, then if that interrupted thread encounters InterruptedException from the internal Condition.await(), it will break the barrier and rethrow the InterruptedException - which is contrary to the "all or none" breakage semantics.

Further, at the time the interrupted thread breaks the barrier, the generation of the barrier has already been advanced, so it is the next generation that gets broken by this threads actions. This means the next group of threads to wait on the barrier will fail for no obvious reason, given that a long time could elapse between uses of the barrier.