support for "readers-writers paradigm" in m-concurrent.h

[mario-tux]

In order to maximize throughput on such thread-safe containers it would be useful to support also the above paradigm (not necessary ref: https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem) using locks and condition variables in order to allow multiple concurrent reads against exclusive writes. This can be alternative to the CONCURRENT_DEF macro.

[P-p-H-d]

Which methods do you think shall support such paradigm?
(See https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock for example of such lock).

[mario-tux]

If you mean, "what priority policies use?", it would depend on the application you are going to implement. Personally I would use the "Read-preferring RW lock" for my application but, again, it depends. I you want to provide a general approach you should implement both (or the three choices). It's up to you.

[P-p-H-d]

Do you plan to use it on complex base type or small one (like int)?

[mario-tux]

Not really small. Does it change something?

[P-p-H-d]

The mechanism for Read Preference presented in https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock can take up to 3 mutex lock/unlock for one read access. The overall cost seems quite high. So I am unsure if such solution will be faster than the simpler one of using one lock/unlock.

Maybe the solution presented in http://www.cs.unc.edu/~anderson/papers/ecrts09b.pdf which uses 2 atomic add for read will be better (but need more work for the _blocking methods).

[P-p-H-d]

I have pushed in master an implementation (with the 3 locks/unlocks for reading) as CONCURRENT_RP_DEF.
Can you tell me the performance compared with plain CONCURRENT_DEF?

[P-p-H-d]

I have pushed in master another implementation (based on atomic_add) as CONCURRENT_RP2_DEF.
Could you tell me which one is better?

[mario-tux]

I was not able to spot a great difference using CONCURRENT_DEF vs CONCURRENT_RP_DEF in my application: there are many other concurrent aspects.
I'm trying to write a small ad-hoc benchmark for this but I got few minors issues (see #40). At the moment I can't spot great difference between CONCURRENT_DEF and CONCURRENT_RP_DEF. On the other side, CONCURRENT_RP2_DEF looks badly slow. If you are interested in the benchmark code I can provide it as long as issue #40 is fixed. Maybe there is something wrong in my bench...

[P-p-H-d]

I am interested in the benchmark code.

[P-p-H-d]

I have updated the bench at https://gist.github.com/P-p-H-d/d517ae44b74096f2cd6ea724cd68211b

• by using get_copy instead of get_at_copy (get_at_copy will create a new entry if the entry is not found, so it modifies the dictionary and as such uses a write lock)
• by using rand_get instead of rand (faster)
• by removing the sleep.

It seems the reads with CONCURRENT_RP are a little bit faster.

I understand why CONCURRENT_RP2 doesn't work but I think I won't fix it and will remove it.

[P-p-H-d]

I have added some basic tests on CONCURRENT_RP_DEF. I don't plan to do anything else on this ticket.

Faster TS_DICT will need dedicated container. It is planned (see ISSUES.org) and I plan to do read without any lock and write with a few CAS. But this is a lot of work of design.

[mario-tux]

Thank you. I will test it again.