5
\$\begingroup\$

I have one writer thread and 10 reader threads of a byte array. It is important to synchronize writes and reads over a "row" (16 bytes).

There are a lot less locks than rows, e.g. in the current configuration 1024 (chunkRows) rows have one lock which makes the overall operation faster, but also consumes less memory.

Here is the read method for ReadWrite locking:

public void read(int pointer, byte[] tmpBytes, int length) {
    Lock lock = locks[pointer / rowSize / chunkRows].readLock();
    lock.lock();
    try {
        System.arraycopy(bytes, pointer, tmpBytes, 0, length);
    } finally {
        lock.unlock();
    }
}

and here for simple "Object"-synchronized:

public void read(int pointer, byte[] tmpBytes, int length) {
    Object lock = locks[pointer / rowSize / chunkRows];
    synchronized (lock) {
        System.arraycopy(bytes, pointer, tmpBytes, 0, length);
    }
}

Here is the full repository which you can easily run via maven. It uses JMH to avoid nasty performance pitfalls. Of course, also write is synchronized similarly.

Now why is my ReadWrite implementation a lot slower than synchronized? (RW is roughly 40% slower)

I like Object-locking more because it uses less RAM but did I made a mistake with ReadWrite-locking or does this make sense?

I tried it on my dual core laptop as well as on more beefy quad core commodity server with simmilar results (Object-locking faster than RW). I get something like 13.0 ops/s for ReadWrite locking and 21.6 ops/s for Object locking.

Update

Several things were wrong in the benchmark which I fixed (maybe there are still glitches)

  • Very important bug fix was to include service.awaitTermination
  • make sure write and read happen at the same time and both are long enough (previously write was too short and nearly no r+w concurrency happened)
  • I've learned about StampedLock, could be slightly faster and also optimistic locking could be even the winner here.
  • minor thing: catch errors in runnable otherwise they won't appear

See all in this commit

\$\endgroup\$
  • \$\begingroup\$ Welcome to Code Review and good job on your first post! Though I still think that there's a simple answer to this that would be likely to get answered on StackOverflow instead, no? Please also update the title to reflect what the code is supposed to do, not what you want to be answered. \$\endgroup\$ – ferada Sep 7 '16 at 15:50
  • 1
    \$\begingroup\$ Thanks ferada. I fear on SO they say it is more related to code review ... we'll see if I can get a satisfying answer. Regarding the title: do you have an example? \$\endgroup\$ – Karussell Sep 7 '16 at 16:25
  • 1
    \$\begingroup\$ I've updated it, but perhaps you can make it more accurate. \$\endgroup\$ – ferada Sep 7 '16 at 17:17
  • \$\begingroup\$ BTW: There could be a more memory efficient solution, which I go through in this question: stackoverflow.com/q/39675003/194609 \$\endgroup\$ – Karussell Sep 24 '16 at 11:39
3
\$\begingroup\$

The documentation of the ReadWriteLock says:

Whether or not a read-write lock will improve performance over the use of a mutual exclusion lock depends on the frequency that the data is read compared to being modified, the duration of the read and write operations, and the contention for the data - that is, the number of threads that will try to read or write the data at the same time. For example, a collection that is initially populated with data and thereafter infrequently modified, while being frequently searched (such as a directory of some kind) is an ideal candidate for the use of a read-write lock. However, if updates become frequent then the data spends most of its time being exclusively locked and there is little, if any increase in concurrency. Further, if the read operations are too short the overhead of the read-write lock implementation (which is inherently more complex than a mutual exclusion lock) can dominate the execution cost, particularly as many read-write lock implementations still serialize all threads through a small section of code. Ultimately, only profiling and measurement will establish whether the use of a read-write lock is suitable for your application.

In your code, the read operations are very short, they are only copying 16 bytes. Probably, the overhead of using a more complex lock is dominating the cost of execution as stated in the documentation.

\$\endgroup\$
  • \$\begingroup\$ Thanks, sounds reasonable! I'll try to increase this, also I'll try to increase the number of write operations e.g. maybe there is just too few time with overlapping reads & writes \$\endgroup\$ – Karussell Sep 7 '16 at 16:23
  • \$\begingroup\$ Via several fixes (see updated question), a lower chunkSize and a bigger rowSize both lockings perform identical. With less locks (bigger chunkSize) RW-locking still 15% slower, for smaller chunkSize even 35% slower. \$\endgroup\$ – Karussell Sep 7 '16 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.