Right, good point wrt single-threadedness. I am just thinking of cases where thread management is centralized, or caller wants to have some control over it -- for example, using fewer threads when load goes up. And even write thread is something that ideally would come from a thread pool.

As with other changes, we can start with this, and iterate.

One more idea: I think the new "p" classes need to go in separate Java package, since there are a few differences; and to outline these distinctions. I think users should be aware of difference and make explicit choice of using parallel implementations.
This because of performance limits (slow input could mean that parallelism won't help at all) that make choice non-trivial for general case.
I can move classes after merge.