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

David Holmes dcholmes at optusnet.com.au
Fri Mar 9 21:03:18 EST 2007


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