RwLock slow to acquire read lock even when uncontended

[jumpnbrownweasel]

Ah! That's exactly the sort of thing I was hoping to come up with.

I was worried that the list of fixed particles may grow large, so copying it each time a particle is added, could be expensive. But if it is really only treated as a list, a persistent data structure would make the append/copy very cheap.

[Compizfox]

@khimru

Yes, but not if you assume that read lock is free. RwLock is more expensive than normal Mutex even if you do read locking (and even more expensive if you do write locking). The only redeeming quality is precisely it's ability to allow work of two readers simultaneously. And if you only do small amount of cheap work under insanely contended RwLock… it just wouldn't work.

I see, thanks. I guess my confusion stemmed from not realizing that merely acquiring read locks on a RwLock (even though that supports multiple concurrent readers) is far from free, and can create a lot of contention.

@the8472

• a variant thereof: see if your problem is amenable to partitioning (tiles? volumes?) e.g. if something like a maximum particle speed bounds the distance at which things can interact per time step

In a way I'm already doing that, since I'm using a cell list to detect collisions. Currently I wrapped the entire cell list in a RwLock, but I'll see if I can do the locking on a finer-grained level (on a per-cell basis).

@jumpnbrownweasel

Unrelated nit: to get n_threads, don't subtract one. The upper bound is exclusive unless you use ..=

I know The reason for the -1 was that I was using one "special" thread to also handle output (not in the example code).

@noamtashma

Here's one idea to reduce read locks, at the cost of threads working off of somewhat stale data.

(I don't know how bad that would be for your needs. but note that in your code, arbitrary changes can happen right after you drop the read guard, before you acquire the write guard - so it already has the potential to work off of stale data, at least in principle).

Hmm, that is true. I didn't realize that.

@noamtashma

The idea is to allow the threads to refresh their list of fixed particles only once in a while.

In order to allow the old lists to remain in memory even when the list is overwritten, store the list in a Mutex<Arc<Data>> instead of an RWLock<Data>.
every one in a while, when your thread refreshes the list, it will lock the mutex, clone the Arc, and immediately drop the mutex to allow others to refresh / rewrite it.

When your thread wants to write to the list, create a new Arc of the new list, and write it into the mutex, replacing the previous Arc.

You'll have to decide how to best handle the fact that you're working with stale data. Maybe if you find a collision, you should check if the data has changed, or rerun it with the new data. Maybe you don't care.

Interesting idea, thanks! I'll look into it.