• Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P2 P2
    • 14
    • None
    • core-libs

      As announced by Doug Lea on
      https://concurrency.markmail.org/thread/kfdv6tg3tnutl4ts

      ```
      The java.util.concurrent.locks classes were among the first classes
      written for j.u.c, and were in increasing need of attention as new
      low-level support and new techniques became available. I did a
      reimplementation of most internals, keeping most of the same basic
      algorithms. Among other improvements, most locks (including
      ReentrantLock) and Conditions are now a bit faster, which also makes
      most BlockingQueues etc faster. Even StampedLock got a refresh; it is
      still our fastest and in many cases best lock. On the other hand,
      prospects for improving ReentrantReadWriteLock are not good, mainly
      because of the read-reentrancy requirements. (Even if you cannot replace
      usages with StampedLock, you may be able to use: ReadWriteLock r = new
      StampedLock().asReadWriteLock()).
      ```

      We want to be able to make (careful!) use of relaxed atomics introduced in recent jdk releases.

      We want to prepare for the Loom project. Loom changes the cost model of spinning/blocking and strongly prefers use of j.u.c. locks over builtin locks (in 2019).

          Loading...

            • Icon: Enhancement Enhancement
            • Resolution: Fixed
            • Icon: P2 P2
            • 14
            • None
            • core-libs

              As announced by Doug Lea on
              https://concurrency.markmail.org/thread/kfdv6tg3tnutl4ts

              ```
              The java.util.concurrent.locks classes were among the first classes
              written for j.u.c, and were in increasing need of attention as new
              low-level support and new techniques became available. I did a
              reimplementation of most internals, keeping most of the same basic
              algorithms. Among other improvements, most locks (including
              ReentrantLock) and Conditions are now a bit faster, which also makes
              most BlockingQueues etc faster. Even StampedLock got a refresh; it is
              still our fastest and in many cases best lock. On the other hand,
              prospects for improving ReentrantReadWriteLock are not good, mainly
              because of the read-reentrancy requirements. (Even if you cannot replace
              usages with StampedLock, you may be able to use: ReadWriteLock r = new
              StampedLock().asReadWriteLock()).
              ```

              We want to be able to make (careful!) use of relaxed atomics introduced in recent jdk releases.

              We want to prepare for the Loom project. Loom changes the cost model of spinning/blocking and strongly prefers use of j.u.c. locks over builtin locks (in 2019).

                    martin Martin Buchholz
                    martin Martin Buchholz
                    Votes:
                    0 Vote for this issue
                    Watchers:
                    3 Start watching this issue

                      Created:
                      Updated:
                      Resolved:

                        martin Martin Buchholz
                        martin Martin Buchholz
                        Votes:
                        0 Vote for this issue
                        Watchers:
                        3 Start watching this issue

                          Created:
                          Updated:
                          Resolved: