What is meant by “fast-path” uncontended synchronization?

前端 未结 3 835
清歌不尽
清歌不尽 2021-02-14 05:18

From the Performance and Scalability chapter of the JCIP book:

The synchronized mechanism is optimized for the uncontended case(volatile is alw

相关标签:
3条回答
  • 2021-02-14 05:46

    There are two distinct concepts here.

    1. Fast-path and Slow-path code
    2. Uncontended and Contended synchronization

    Slow-path vs Fast-path code

    This is another way to identify the producer of the machine specific binary code.

    With HotSpot VM, slow-path code is binary code produced by a C++ implementation, where fast-path code means code produced by JIT compiler.

    In general sense, fast-path code is a lot more optimised. To fully understand JIT compilers wikipedia is a good place to start.

    Uncontended and Contended synchronization

    Java's synchronization construct (Monitors) have the concept of ownership. When a thread tries to lock (gain the ownership of) the monitor, it can either be locked (owned by another thread) or unlocked.

    Uncontended synchronization happens in two different scenarios:

    1. Unlocked Monitor (ownership gained strait away)
    2. Monitor already owned by the same thread

    Contended synchronization, on the other hand, means the thread will be blocked until the owner thread release the monitor lock.

    Answering the question

    By fast-path uncontended synchronization the author means, the fastest bytecode translation (fast-path) in the cheapest scenario (uncontended synchronization).

    0 讨论(0)
  • 2021-02-14 05:49

    I'm not familiar with the topic of the book, but in general a “fast path” is a specific possible control flow branch which is significantly more efficient than the others and therefore preferred, but cannot handle complex cases.

    I assume that the book is talking about Java's synchronized block/qualifier. In this case, the fast path is most likely one where it is easy to detect that there are no other threads accessing the same data. What the book is saying, then, is that the implementation of synchronized has been optimized to have the best performance in the case where only one thread is actually using the object, as opposed to the case where multiple threads are and the synchronization must actually mediate among them.

    0 讨论(0)
  • 2021-02-14 06:01

    The first step of acquiring a synchronized lock is a single volatile write (monitor owner field). If the lock is uncontested then that is all which will happen.

    If the lock is contested then there will be various context switches and other mechanisms which will increase clock cycles.

    0 讨论(0)
提交回复
热议问题