[concurrency-interest] Concurrency-interest Digest, Vol 26, Issue 7

Peter Veentjer alarmnummer at gmail.com
Sat Mar 10 07:17:34 EST 2007


True, a different thread could have reset the interrupt-status while
the interruptedexception is handled.


On 3/10/07, David Holmes <dcholmes at optusnet.com.au> wrote:
> Peter,
>
> I think what you have is workable. Note that your asserts aren't valid -
> they assume only single interrupts are targeted at a given thread.
>
> David Holmes
>
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> > Veentjer
> > Sent: Thursday, 8 March 2007 7:02 PM
> > To: dholmes at ieee.org
> > Cc: concurrency-interest at cs.oswego.edu; Martin Buchholz
> > Subject: Re: [concurrency-interest] Concurrency-interest Digest, Vol
> > 26,Issue 7
> >
> >
> > Hmmm.. I have thought about your replay David.
> >
> > At the moment I'm writing some concurrency utility classes, and I most
> > of them contain something like this:
> >
> > foo
> > fooUninterruptibly
> > tryFoo(long,timeUnit)
> > tryFooUninterruptibly(long,TimeUnit)
> >
> > The problem is that you get a lot of methods only differ in the fact
> > that the call is interruptible or not. I think I have found a solution
> > for the case where a non interruptble version is needed, without
> > writing all the methods.
> >
> > I have created the following classes:
> >
> > public abstract class UninterruptibleCall<E> {
> >
> >     public abstract E executeInterruptible() throws InterruptedException;
> >
> >     public E execute() {
> >         boolean restoreInterrupt = Thread.interrupted();
> >         try {
> >             while (true) {
> >                 try {
> >                     return executeInterruptible();
> >                 } catch (InterruptedException ex) {
> >                     assert !Thread.currentThread().isInterrupted();
> >                     restoreInterrupt = true;
> >                 }
> >             }
> >         } finally {
> >             if (restoreInterrupt)
> >                 Thread.currentThread().interrupt();
> >         }
> >     }
> > }
> >
> > public abstract class TimedUninterruptibleCall<E> {
> >
> >     public abstract E executeInterruptible(long timeout, TimeUnit
> > unit)throws InterruptedException, TimeoutException;
> >
> >     public E execute(long timeout, TimeUnit unit)throws TimeoutException{
> >         long timeoutNs = ConcurrencyUtil.toUsableNanos(timeout,unit);
> >
> >         boolean restoreInterrupt = Thread.interrupted();
> >         try{
> >             while(true){
> >                 long startNs = System.nanoTime();
> >                 try {
> >                     return executeInterruptible(timeoutNs,
> > TimeUnit.NANOSECONDS);
> >                 } catch (InterruptedException e) {
> >                     assert !Thread.currentThread().isInterrupted();
> >                     restoreInterrupt = true;
> >
> >                     timeoutNs -= System.nanoTime()-startNs;
> >                     if(timeoutNs<=0)
> >                         throw new TimeoutException();
> >                 }
> >             }
> >         }finally{
> >             if(restoreInterrupt)
> >                 Thread.currentThread().interrupt();
> >         }
> >     }
> > }
> >
> >
> > usage example:
> >
> > void foo(){
> >     CallUninterruptibly call = new CallUninterruptibly(){
> >           void executeInterruptibly()throws InterruptedEx{
> >                  blockingQueue.put("foo");
> >                  return null;
> >           }
> >    }
> >
> >    call.execute();
> > }
> >
> > These can be used to get a non interruptible version of an
> > interruptible call. It is just a proof of concept, I haven't tested
> > them so they could contains bugs. But I hope you get the point. If
> > this is usable, it means that I can remove all the non uninterruptible
> > methods.
> >
> >
> >
> > On 3/7/07, David Holmes <dcholmes at optusnet.com.au> wrote:
> > > In early 2003 we thrashed out the details of the timed-blocking
> > methods. At
> > > that time we opined that anyone prepared to handle timeouts
> > should also be
> > > prepared to handle interrupts. We added awaitUninteruptibly as
> > a concession
> > > to the occasional need to have to wait for some condition regardless of
> > > cancellation requests, and because it was a trivial implementation.
> > > Generally the blocking methods do not have non-interruptible
> > forms because
> > > they are all considered cancellation points.
> > >
> > > If we added awaitNanosUninterruptibly you could argue that all
> > > timed-blocking methods should have an uninterruptible form. I
> > don't think
> > > they are needed often enough to warrant library inclusion.
> > >
> > > Cheers,
> > > David Holmes
> > >
> > > > -----Original Message-----
> > > > From: concurrency-interest-bounces at cs.oswego.edu
> > > > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Martin
> > > > Buchholz
> > > > Sent: Wednesday, 7 March 2007 1:31 PM
> > > > To: concurrency-interest at cs.oswego.edu
> > > > Subject: Re: [concurrency-interest] Concurrency-interest Digest, Vol
> > > > 26,Issue 7
> > > >
> > > >
> > > > Peter Veentjer wondered,
> > > >
> > > > "I was wondering why the Condition.awaitNanosUninterruptibly(long)
> > > > method is missing. You are able to do an uninterruptible wait on the
> > > > Condition without a timeout, but you are not able to do an
> > > > uninterruptible wait on a Condition with a timeout."
> > > >
> > > > I've wondered the same thing myself in the past.
> > > >
> > > > Should Peter's static method be added to the JDK somewhere?
> > > > Unfortunately, we cannot add new methods to existing interfaces.
> > > >
> > > > Martin
> > > >
> > > > _______________________________________________
> > > > Concurrency-interest mailing list
> > > > Concurrency-interest at altair.cs.oswego.edu
> > > > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > Concurrency-interest at altair.cs.oswego.edu
> > > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


More information about the Concurrency-interest mailing list