How RecursiveTask works for calculating Fibonacci numbers? - recursion

Question

I am looking at the classical example for RecursiveTask calculating Fibonacci numbers. I added some output: see http://jboston.net/2017/FibonacciOutp.txt, the code is below
Still cannot understand how this is working, why first we see all numbers decreasing from 12 and then repeating many times
number=2 fcal1.join()=1 fcal2.compute()=0
number=3 fcal1.join()=1 fcal2.compute()=1
The code:
import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.RecursiveTask;
public class RecursiveTaskDemo {
public static void main(String[] args) {
FibonacciCal fibonacciCal = new FibonacciCal(12);
ForkJoinPool pool = new ForkJoinPool();
int i = pool.invoke(fibonacciCal);
System.out.println(i);
}
}
class FibonacciCal extends RecursiveTask<Integer> {
private static final long serialVersionUID = 1L;
final int num;
FibonacciCal(int num) {
this.num = num;
}
#Override
protected Integer compute() {
if (num <= 1) {
return num;
}
System.out.println("number=" + num);
FibonacciCal fcal1 = new FibonacciCal(num - 1);
fcal1.fork();
FibonacciCal fcal2 = new FibonacciCal(num - 2);
int fcal1Join = fcal1.join();
int fcal2Compute = fcal2.compute();
System.out.println("number=" + num + " fcal1.join()=" + fcal1Join + " fcal2.compute()=" + fcal2Compute);
return fcal2Compute + fcal1Join;
}
}

Answer 1

When FibonacciCal::compute is called, it forks off one thread to calculate fib(n - 1) and computes fib(n - 2) in the starting thread. The branching looks a bit like this (fib(n) represents a thread running FibonacciCal(n).compute()):
STARTING WITH pool.invoke(new FibonacciCal(5)):
fib(5)
A BIT LATER:
fib(5) === fib(3) // The fibcal2.compute() call, printing num = 3
\== fib(4) // The fibcal1.fork() call, printing num = 4
LATER:
fib(5) === fib(3) === fib(1) // These fib(0/1)s are base cases and will start folding the tree back up
| \== fib(2) === fib(0) // Will return 1 and not fork
| \== fib(1) // Will return 1 and not fork
\== fib(4) === fib(2) === fib(0)
| \== fib(1)
\== fib(3) === fib(1)
\== fib(2) === fib(0)
\== fib(1)
METHODS START RETURNING:
fib(5) === fib(3) === 1
| \== fib(2) === 1
| \== 1
\== fib(4) === fib(2) === 1
| \== 1
\== fib(3) === 1
\== fib(2) === 1
\== 1
ADDITIONS START HAPPENING:
fib(5) === fib(3) === 1
| \== (1 + 1) = 2 // When a thread joins its child, it prints out its number again.
| // Since the tree is now folding instead of unfolding, the printlns appear, approximately, the opposite order
\== fib(4) === (1 + 1) = 2
\== fib(3) === 1
\== (1 + 1) = 2
LATER:
fib(5) === (1 + 2) = 3 === 1
| \== 2
\== fib(4) === 2
\== (1 + 2) = 3 === 1
\== 2
END:
8 === 3 === 1
| \== 2
\== 5 === 2
\== 3 === 1
\== 2
The reason you get a lot of repeating numbers is because there isn't any memoization. In this example with fib(5) you see that you get 8 base terms of fib(0) or fib(1), 3 terms of fib(2), 2 of fib(3), and one fib(4). As the lower order terms start joining their children you get lots of printlns with small nums, until the end comes and they start counting back up.