I'm afraid, this PR wasn't helpful enough for utilizing modern multicore CPUs:

Firstly it is NOT about parallel transaction verification, instead it postpones script verification by queuing it for a future multi thread processing which is called right before ending the block verification that is done single thread the joins to the final multi-thread script processing. The logic behind such a sophisticated scheme apparently has something to do with transaction packages where we have transactions with fresh inputs that are outputs of other transactions in the same block. I've proposed an algorithm for handling this situation BTW.

Secondly, it uses cs_main lock excessively, keeping the lock constantly active through the script verification itself, hence leaving little room for parallelism to have a scalable impact on the block verification process. In practice, it has been experimentally shown (and even discussed in the PR 2060 related comments) that the overhead of the scheme rapidly outperforms gains once it is configured for utilizing more threads than the actual CPU cores and it stays around 30% improvement with 4 Cores, not an encouraging result and far from scalable behavior.