Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use simple mutexes for cases where RDLOCK is not native. #23
This is exactly the same as using two mutexes because
So it is simpler & faster to use just a single lock.
Once that is in place, the RDLOCK for the native READLOCK has a race condition
ref_count++ | ref_count--
for the cache entry can run in two parallel processes with ambigous results.
The gcc/vc++ intrinsics for the atomic increments remove this race condition
__sync_add_and_fetch(ref_count) | __sync_sub_and_fetch(ref_count)
will run safely in parallel, as they lock each other out during the read-modify-write sections.
The reason two mutex are used is to simplify logic, assume a rwlock always exists, and prefer readers. If you can produce test results that I can see that say that using a single mutex keeps the application moving faster I'd be interested to see them, but during testing it did not seem to be the case.