Support StampedLock #9
Comments
l0s
added a commit
to l0s/xsync
that referenced
this issue
Jun 22, 2020
This adds two new factories that generate `StampedLock` and `ReadWriteLock` instances for applications that require more granular control over locking. The unit tests duplicate the verifications in `XMutexFactoryImplTest` and also introduce verifications specific to the synchronisation mechanisms. Addresses: antkorwin#9
l0s
added a commit
to l0s/xsync
that referenced
this issue
Jun 22, 2020
This adds two new factories that generate `StampedLock` and `ReadWriteLock` instances for applications that require more granular control over locking. The unit tests duplicate the verifications in `XMutexFactoryImplTest` and also introduce verifications specific to the synchronisation mechanisms. Addresses: antkorwin#9
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Introduce a
StampedLockFactorysimilar toXMutexFactory, except instead of generating a synchronization monitor, it would generate aStampedLockinstance. This would be useful for applications that could benefit from the performance characteristics ofStampedLock: https://blog.overops.com/java-8-stampedlocks-vs-readwritelocks-and-synchronized/ . It would also be useful for applications that need read-locking vs. write-locking semantics, i.e. allowing multiple concurrent readers provided there are no writers.Optional: Also introduce a
ReadWriteLockFactorywhich would be useful for applications that prefer the simplerReadWriteLockinterface, require re-entrant capabilities, or need to define whether or not the lock is fair.The text was updated successfully, but these errors were encountered: