Now, let's consider the three design schemes for parallel backtracking that were previously covered. Spawning a task for each recursive call that seeks to further explore the partial solution (Design 1) is easy to implement. A specific workload I used to test my solution code was a 24x15 grid that contained one 4-square, four 3-squares, 14 2-squares, 20 1-squares, four 0-squares, and 41 plain black squares. If none of the numbered squares had an adjacent black square reducing the available open adjacent white squares, this workload could potentially generate over 1.723E+21 (sextillion) tasks from the numbered squares alone. It's difficult to compute how many more tasks would be spawned from covering the remaining white squares. With such a mind-boggling task pool size, though, do we really want to know?

The final two designs can be done, as I showed in the NQueens() codes, with functions that spawn new tasks and versions that don't. A quick cut-and-paste and some added code lines can put the duplicated code into play. (You could keep the amount of code smaller by adding some conditional tests to decide whether or not to spawn a task at a recursive call, but, for me, the duplicated code is easier to understand.)

Each Akari puzzle is different and will have a different mix of numbered squares; plus, the number of legal bulb placement moves to be tested varies depending on the number in the square. The big question for the second (spawn all tasks at some level) and third (spawn tasks down to some level) design schemes is how to best arrange the numbered black squares to achieve the best performance. I wish I had some definitive advice to pass along, but the dynamic nature of the puzzles makes that almost impossible. Given enough sample inputs, you should be able to formulate some guidelines that will yield acceptable performance in the general situation.