- A decent read/write mutex... - 2 Updates
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 25 01:51PM -0700 On 4/15/2017 10:47 PM, Chris M. Thomasson wrote: > If you read all of the data in the links, one can implement it for > themselves. Is there any interest in my upcoming pure c++ std impl of > this rw-mutex? Thanks. Fwiw, I am trying to think of a decent example program to build using my rw-mutex algorithm. Humm... Perhaps something simple like reader threads iterating through a shared std::deque, and two classes of writer threads adding and removing items at random. We can take the total number of reads performed during the test as an "idea" of the "reader throughput". Actually, imvho, it would be better to take the total number of reads an _individual_ reader thread performs. Then make a list like, btw the numbers are totally randomly typed in here. The actual test would make real data: // example output reader[0] = 213213312 reads reader[1] = 284575201 reads reader[2] = 254488774 reads reader[...] = ... reads Then I will compare it to a single std::mutex based impl where we all can see the difference in the number of reads performed. In all of my experience, a rw-mutex outperforms a single mutex setup. A decent rw-mutex will allow more reads to be performed per-reader thread. Once this is completed, I can compare my rw-mutex to another way of solving the reader-writer problem using something called proxy garbage collection in pure std c++. The proxy collector will get better numbers than the rw-mutex. Any ideas wrt the type of test I should create? The rw-mutex is ready to be ported to std c++, ready to be taken out of the Relacy unit-test realm. Getting rid of that damn seq_cst barrier wrt making it conditional was essential. :^) |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 25 02:46PM -0700 On 4/25/2017 1:51 PM, Chris M. Thomasson wrote: > On 4/15/2017 10:47 PM, Chris M. Thomasson wrote: >> Fwiw, here is some background, if interested please _read_all_: >> https://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/296471 [...] > The rw-mutex is ready to be ported to std c++, ready to be taken out of > the Relacy unit-test realm. Getting rid of that damn seq_cst barrier wrt > making it conditional was essential. Fwiw, the Windows implementation: http://webpages.charter.net/appcore/misc/rwmutex_win_hpp.html used the normal InterlockedIncrement: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683614(v=vs.85).aspx It is documented as emitting a full barrier, eg.g seq_cst. The old win code did not use any special ones like InterlockedIncrementAcquire: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683618(v=vs.85).aspx This C++11 version is more efficient. Now, the interesting thing is that we can ifdef out the seq_cst fence on x86 systems because the LOCK prefix provides the seq_cst relationship by default. The C++11 code on an x86 will emit an MFENCE or dummy LOCKed atomic op for the seq_cst. This is not needed on said arch. Now, on a SPARC in say RMO mode, well, the seq_cst better damn well be there! ;^) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment