Total Throughput of Persistent Data Structures vs. Locking

I wonder if anyone has done a study on this. Let’s imagine a 64 core server (8 CPUs with 8 cores each) and think what would happen in the following 2 scenarios:

1) We use persistent data structures (PDS) so each core can go on its merry way without having to worry about about concurrency that much except perhaps at some integration point or something else.

2) Each core will request a lock on what it needs when it needs to, then immediately move on to other work while it waits to receive the lock.

There are some assumptions here: that we do have a situation where the PDS case has been structured such that it doesn’t have dependencies, and that there is useful work for every core to do while waiting for locks.

Is it reasonable to do useful work while waiting for lock? If not, we’ll have to take the case where we have to wait for locks synchronously.

Either way, which would be greater: the overhead in managing locks, or the overhead in the more expensive operations on PDS vs. mutable data structures?

This question probably really needs a very specific case to talk through, but it’s something that just occurred to me.

When I have a large mutable structure and am approaching it in a PDS way, I would stick it in one place, probably owned by a single thread and all change requests handled by it. Then it sends out updates. This model works very well  because those updates it sends out are immutable so the receivers of the updates never have to synch on the data they receive. In a destructive update case, it would have to do a defensive copy to avoid the synch which would be much more expensive. But would a lock be less expensive?

If we think in terms of threads never blocking by just switching to other useful work–is it possible to have higher throughput this way? Though I could see how things could get extra messy… not sure.