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

Peter Veentjer alarmnummer at gmail.com
Thu Mar 8 04:02:01 EST 2007


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
>


More information about the Concurrency-interest mailing list