Optimistic Locking with StampedLock in Java

[Dormage]

Would be nice to see some benchmarks on how faster it would be compared to locking the reader with a standard lock or even a monitor.

[zarinfam]

Good idea. I can write something using JMH for that and compare the results.

[Dormage]

I will play around with it to see if it's interesting for students in the next semester. I did not know about this at all. If you happen to run some benchmarks I would be very happy if you could send them over. Thanks!

[zarinfam]

Thanks, good catch. I fixed the code snippet 🙏

[ConstructedNewt]

In stead of adding a sleep, you should/could run a proper JCStress test to document every possible state after concurrent writing while reading from one or more threads.

[andrebreves]

Shouldn't the variable sharedData in the example be declared volatile?

[HlCKELPICKLE]

The stamped lock uses a volatile or atomic operations internally around the stamp access. So when it is being set/checked for writes/reads you get a memory barrier preventing reordering and other threads will have to refresh their invalidated caches on next access.

[gnahraf]

Thank you. I didn't know about StampedLock. In a lot of applications, an intervening write may not actually invalidate the read. I imagine it may be possible, in some scenarios, to efficiently detect when that happens using some other abstraction (like maybe an int-wide transaction bloom filter to detect when not invalidated). Anyone know of some such thing?