4

I (a newbie) am testing my concepts about Scala's Futures and the right patterns to use them.

The premise
Scala's futures are blocks of code to be executed asynchronously. So, the main thread creates one or more such futures, installs onSuccess() [note: equally applicable to OnComplete/onFailure] callbacks and proceeds. The callbacks are executed as and when the futures complete their runs.

Presumably, these callbacks generate results which are supposed to be used by the main thread. The results are stored in a Try[T] container, with a write-once/read-many constraint. The main (or any other thread but that is not the point) decide when to peak in the container and collect the results for further processing.

Whichever discussion/blog/API I have laid my eyes on so far, mentions the fact that main thread doesn't have to wait: it can carry on doing its own thing, allowing the futures to be executed in parallel and be ready with the result.

Question

But my question is: in the simplest case, where it has finished doing whatever it is doing, the main thread will have to wait for the callbacks to finish, will it not? And, because there is no interruption mechanism provided which can indicate that the future has finished execution, the main thread has no option but to 'wait' (possibly with a time-limit) for the result to be ready? In other words, in an application, where futures are employed, a wait is ultimately unavoidable, isn't it?

Note
I understand that we can chain the futures, using combinators or Promise (and there are other patterns too), to avoid this issue altogether. But, I am trying to clarify my concept that under certain cases, using futures doesn't obviate the need to wait for them to finish.

Is it too elementary a question? Is it showing a big void in my understanding?

Improve this question
9
  • Note that there is no need in "main thread" at all, you could use only futures and actors without "main thread" and all code will be in callbacks. For instance it play framework there is no "main thread". You could also check in main thread if future is completed and that perform some actions without waiting. Commented Feb 4, 2014 at 17:27
  • You presume that the thread of execution / execution context that initiates a Future is the ultimate consumer of it. That is not necessarily so. However, whatever computation does consume that value must wait for it, of course, but even that need not be done by waiting. As you observe, it can be delivered via one of the completion handlers. It is in fact possible to write systems that never Await a Future, but rather do everything asynchronously. Commented Feb 4, 2014 at 17:38
  • Why would the main thread wait for futures to finish? Unless it is doing an await or something there would be no need. I think the confusion you have here is probably because you expect that JVM will only shutdown when main thread exists? Commented Feb 4, 2014 at 17:40
  • @senia, I understand that a 'main thread' is not necessary. The app can work on the basis of a bunch of well-orchestrated callbacks. Agreed. Mine was more of theoretical, conceptual Q. Commented Feb 5, 2014 at 2:26
  • @RandallSchulz, That presumption was to make a basis for my question. Almost always, this is not the case. Agreed. Say, the main thread needs to collect last 10 tweets from 3 different friends. So, it fires 3 futures, each meant for 1 friend! The collection cannot be formed till three futures finish, right? So, main thread has no option but to wait for all three to be done. That was my point. Commented Feb 5, 2014 at 2:37

1 Answer 1

Reset to default
3

It would be useful to understand the theoretical difference between Await and async. These are known as blocking and non-blocking respectively.

Blocking

A blocking computation is much like a while loop.

while(!done) { if (isDone) { // do whatever done = true } }

This is synchronous blocking computation. The Thread can't do anything else until the blocking action is complete as its constantly checking for the action.

You only really have as many threads as processors on the machine. Hopefully you can see how they can quickly be fully occupied and a giant FIFO queue of "things to do" is formed.

Non-blocking

In essence, the concept is very simple. Instead of continuously checking if something is done, the check is done at given time intervals. The Future will be checked for completion every 100ms(let`s say).

The awesome thing is during every one of those 100ms breaks, the Thread is free to do something else. That's why you get superior performance from async things.

Bottom line

It's physically possible for the processors to do more things in a given time interval. It's a very simple syllogism.

Say you and your friend arrange to meet for coffee at 3PM. He doesn't show up.

You can either sit in the coffee shop relentlessly cursing or you can go home and bake cookies. While the cookies are baking, you check your phone every 5 minutes until he eventually texts and then you meet up.

In scenario 1, you are angry and haven't done much all day.

In scenario 2, you are delighted by your culinary success and in a great mood to see a friend.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

+1 for biased Bottom line :D. But since your 'friend' can't tell you that he will arrive at a given time, you rather run to the coffee shop like every hour to check if he has arrived.
I think example would be better if you say that the friend will send you a text message when he arrives at the coffee shop. Then while you are baking cookies you check your phone every few minutes to see if he has messaged you.
@flavian While I am baking the cookies, I am checking the SMS box periodically is equivalent to a busy wait loop (letting time elapse idly or doing meaningful work and checking content of SMS box), isn't it? If so, isn't the 'main thread' (me) waiting for something to happen, in this case, an asynchronous task to finish (SMS from friend)? This is different from the scenario where I keep baking, SMS arrives, handset blings, I am informed of its arrival, I finish the current step of baking and then decide whether to drink a glass of water or check. Are we on the same page?
Gentlemen, sorry for a late show up. Thanks for all the replies/comments. @flavian, from your post earlier, 'The Future will be checked for completion every 100ms(let`s say)' is what gives me the answer I am looking for. If the checker (main thread in my premise) has things to do - and in a well-designed arrangement, it almost always will - it will do them and come back to check if the future is completed. If it has nothing do (bad design, I know), then it will effectively wait for the completion. I don't know how to 'accept' an answer. So, please consider this comment as an acceptance.
I think this doesn't answer the question. OTOH, not sure the OP understood the question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.