read-write lock with writer-preference

[Karry]

C++ std::shared_mutex may lead to writer starvation with multiple highly concurrent readers, and it doesn't provide API to configure priority. Luckily, with Pthread implementation, we may configure writer preference. It expect that write operations are rare, compared to read ones.

This problem (writer starvation) is visible during navigation, when multiple threads reads database with every position update (renderer thread and navigation thread). When you drive to the tunnel and application change style to nigh one (daylight flag setup to false), it may take several minutes to change map style - because style-sheet change requires write lock to databases...

[sonarcloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[janbar]

For this case you could use the "no lock concept", using an atomic operation on int, as follows:

• the reader load(atomic) value, then test it for 0. if not 0 then yield and loop for next load(atomic) ...
• the writer "lock" by fetch_and_add 1. when works is finished, the writer store(atomic) 0.

Using this algorithm the writer always takes priority and you don't need mutex. The performance is therefore much better.

edit: I will post a sample implementation of ReadWriteLock using this algo.

[Karry]

the reader load(atomic) value, then test it for 0. if not 0 then yield and loop for next load(atomic) ...

but this is spinlock - it is good for write operations that are really fast, but in our case, it is better to block the thread I believe...

[janbar]

I prepares a PR with the sample. Currently I made that thread writer must wait all readers have freed the lock. So One question, is a writer must wait all reader are freed ?

[Karry]

Yes, because readers are expecting that structures will not be modified by writer when they are holding the lock...

[janbar]

Karry, I made the PR for your branch.

[Framstag]

Hello @Karry , hello @janbar : I missed this PR. Sorry. Should I now still wait or merge?

[Karry]

Please wait - @janbar prepared another implementation Karry#2 that is not using pthread, just STL locking primitives. It will provide write precedence on all platforms...

[janbar]

@Framstag , I created the new PR #1555 for the new implementation of the lock.

[Framstag]

@Karry : This one is now obsolete?

[Karry]

@Karry : This one is now obsolete?

yes, but I still have some doubts about @janbar implementation...