Futures and Concurrent Programming

Discussions

News: Futures and Concurrent Programming

  1. Futures and Concurrent Programming (7 messages)

    Brian McCallister talks about the concept of "Futures" and how they "provide for much more natural and easy to use concurrent design than Java style threading and monitors." He goes on to provide code to show an implementation, and then later finds that we have them in Java 5!

    Futures and Concurrent Programming (Part 1)
    FutureTask<String> future =
      new FutureTask<String>(new Callable<String>() {
        public String call() {
          return searcher.search(target);
      }});
    executor.execute(future);

    Java 5 Future

    Threaded Messages (7)

  2. futures and continuations[ Go to top ]

    The recent post on continuations made me realize that we might use futures in combination with continuations for defining unit of works. Thus a unit of work, or business process, does not need to know how it's data is procured. Specifically it hides what I call the 'screen granularity'; more mobile phone pages are needed to obtain the necessary data for a unit of work than browser pages at 1280*1024 resolution.
    So the use of futures might obviate the need for sendAndWait() calls in a continuation. The business process blocks and is persisted until it's variables are bound to a value.

    Very interesting stuff.

    groeten uit Nederland


    btw Gregor Hohpe showed at Javapolis in Antwerp a nice example of the use of futures in interfacing between callstack based synchronous programming and event-driven asynchronous, as is often encountered in application integration scenario's.
  3. Futures and Concurrent Programming[ Go to top ]

    i like very much

    war purdy -1
    c-shit-0 davies -1

    heh
  4. The Dude[ Go to top ]

    Are you brain-dead ?
    No, really, are you ?
    Message, style, spelling, key ingredients to successful written communication.
  5. Futures and Concurrent Programming[ Go to top ]

    Swing needs to be async like Flex is, so that you can populate a DB and not freeze the UI.
    Of course... JDNC chose to write a Swing worker, and not use any of this.

    I do not quite know why, I just know the main place threads are uses is Swing, and they are using Swing worker, FYI.

    Vic
    sandraSF.com for RiA-SoA
    boardVU.com for live sample
  6. Swing threads[ Go to top ]

    In a Swing application I've been developing for about 8 years now, I notice a certain pattern occuring in all my Swing threading.
    - Upon a event split from Swing worker thread
    - Upon a set or get, do a InvokeAndWait.

    I was wondering what would happen if we used AOP to catch all "fireXXX" methods and reinvoke a call in a separate thread, then catch all setXXX and getXXX (actually all other methods) any resync them with the worker thread using InvokeAndWait.

    In principle this would make Swing threading but it would result in a different behaviour, so it is not backwards compatible.
  7. Swing threads[ Go to top ]

    I was wondering what would happen if we used AOP to catch all "fireXXX" methods and reinvoke a call in a separate thread, then catch all setXXX and getXXX (actually all other methods) any resync them with the worker thread using InvokeAndWait.In principle this would make Swing threading but it would result in a different behaviour, so it is not backwards compatible.

    I guess this would also result in something only few people can understand and practically debug.
  8. Functional Programming[ Go to top ]

    Is it the real future?

    I like FP.

    -Abhijit