I can impart one bit of wisdom to give you a chance at an efficient approach: Control the order of black squares handled. For Design 2, you want to spawn the number of tasks that will be a multiple of the number of threads to ensure enough work per thread. Design 3 spawns tasks until enough tasks are available to keep all threads busy. Even if the number of threads is known, how can you predict the number of tasks that will be spawned? This is especially true since you can't know how previously placed bulbs might affect what moves are available at the next numbered square to be processed. In the case of Akari, if you know the order of the numbered squares to be examined, you can compute the maximum number of tasks that might be spawned for a given design scheme (and maybe extrapolate the actual number of tasks that would be spawned). A corollary to this advice would be to handle the 3- and 1-squares before the 2-squares since bulbs placed around the former will tend to cut down on the number of open squares around the latter and, hence, the number of potential tasks.

If all of my 4000 words on this topic have failed to impress you, let me impart one last demonstration of the power of the backtracking algorithm to solve Akari puzzles. Of the 1.723 sextillion possible tasks from the workload with 38 numbered squares, only 19066 were actually spawned (with a copy of the grid allocated). Of those, only 7296 ended up making the recursive call to further explore the new grid configuration after making sure the adjacent white squares were open. I ended up with a 22.5X speedup on 80 threads for this one workload.