0

I'm implementing a custom FutureTask (not extending) for use in thread pools, and so on. I need special features and cannot extend directly upon FutureTasks methods. To help me do this, I looked at the default implementation. You can see the default implementation here, if you cannot access the code:

http://pastebin.com/HTe6WT9S

As you can see, it uses AbstractQueuedSynchronizer. My question is simply why? Is this class super-optimized or is it mainly the FIFO feature which is attractive? My initial idea was to implement my custom FutureTask using an AtomicInteger and other low-level constructs, using my average knowledge of good synchronous constructs to implement my FutureTask optimally, so I might not want AQSs slower features, if there are any. So are there any other features AQS offers? Any good arguments for/against using it? This is my limited guess so far:

AQS * Maybe the de facto standard, because it's what you should use in the general case (pro) * Can copy most of the code (pro) * The FIFO feature is interesting, but is it desirable for a FutureTask? (neutral) * Perhaps its features makes it slower than low level constructs? (con) AtomicInteger & other low-level constructs * Probably as fast as you can get? (pro) * Have to implement self ((minor) con) * No FIFO (con)

bombax
  • 1,189
  • 8
  • 26

1 Answers1

1

I just answered what's AQS used for. Please read it first.

A FutureTask instance can be hold by many different threads. For example:

    final FutureTask<Beef> killCows = new FutureTask<Beef>(
            new Callable<Beef>() {

                @Override
                public Beef call() throws Exception {
                    return new Beef();
                }
            });

    new Thread(new Runnable() {

        @Override
        public void run() {

            Beef beef = killCows.get();
            // prepare sirloin

        }
    }).start();

    new Thread(new Runnable() {

        @Override
        public void run() {

            Beef beef = killCows.get();
            // prepare rib

        }
    }).start();

All of the threads that call FutureTask.get() will wait(blocked) until the task is done or cancelled. There must be some mechanism to notify and wake them up. So the answer is AQS. As you mentioned, it does make a FIFO queue, each node in the queue stands for a thread. Once the task is done, all the nodes will be notified and have the permission to access the critical section one by one.

Please don't make another FutureTask but understand it first. Maybe you can override those protected methods like done() to finish your job.

Community
  • 1
  • 1
Anderson
  • 2,496
  • 1
  • 27
  • 41
  • I'm afraid I can't - I've basically looked at all opportunities to do this, but I have to implement my own. But thanks a lot for your very helpful answer! – bombax Dec 11 '13 at 19:36
  • @bombax You may talk more about your requirement as another question. Let's check if it does need a new FutureTask. – Anderson Dec 12 '13 at 02:39
  • Thanks! The requirement and all its gory details, including the motivation behind all this, is right here: http://stackoverflow.com/questions/20552211/java-swing-halting-the-event-dispatch-thread-activity-temporarily-v7#20552211 – bombax Dec 12 '13 at 19:16