4 ms·
While it is true that lock free data structures provide much better throughput in highly contended environments people forget that in the many reads/few writers
by voidlogic 12y ago
While it is true that lock free data structures provide much better throughput in highly contended environments people forget that in the many reads/few writers situations they often are slower the Read/Write mutexes. Maybe some of the upcoming transactional memory instructions will improve this, but for the time being, and probably always- benchmark your code!
- readerrrr 12y agoIn that case you can add signals and send threads to sleep if there is not enough elements on the stack, and wake them up if the stack starts growing faster.
- jacquesm 12y agoBut you're still burning more cycles, this isn't just about spinning read threads without input.
- davidtgoldblatt 12y agoEven if you're read mostly, R/W locks often do a very bad job. If your critical sections are short (say, in a hash map, or fine-grained locks in a linked list or tree, or even a whole structure lock on a small tree or array), then contention on the R/W lock internals will be a bottleneck, since readers still have to update the reader count, so the count field is a shared location all the readers are doing writes to. You could have this by e.g. having a "fat" R/W lock that's made up of num_cpus primitive R/W locks (and each reader only reader-locks the lock associated with its CPU), but none of the common R/W locks actually do this (and it's not always even the right call if you're worried about node size). Then again, lots of lock-free structures often try to handle memory management using reference counts or hazard pointers, which have their own performance issues.