2015-06-02 17 views
11

Java 8 đã thêm ba hàng rào vào sun.misc.Unsafe.Tài liệu Java Unsafe.storeFence() sai?

Tôi cảm thấy bối rối sau khi đọc tài liệu của họ.

Vì vậy, tôi đã tìm kiếm trên web và tìm thấy điều này link.

Theo trang ở trên, tôi tin rằng các phương pháp này gần như không có gì trong thực tế. Đúng nếu tôi sai, gần như nói, loadFence(), storeFence() và fullFence() tương ứng với đọc dễ đọc, viết lười và viết dễ bay hơi, mặc dù về mặt kỹ thuật, các hàng rào này mạnh hơn các biến dễ bay hơi. Vì vậy, loadFence() là một hàng rào có được, và storeFence() là một hàng rào phát hành, và fullFence() là hàng rào đầy đủ.

Nhưng sau đó tài liệu cho storeFence() trông lạ.

Nó nói,

/** 
* Ensures lack of reordering of stores before the fence 
* with loads or stores after the fence. 
*/ 
void storeFence(); 

Đó không giống như một hàng rào phát hành. Làm thế nào là nó phải được sử dụng? Không nên nó được

/** 
* Ensures lack of reordering of loads or stores before the fence 
* with stores after the fence. 
*/ 
void storeFence(); 

tôi giả trước nghĩa trước đó và sau nghĩa sau.

EDIT

tôi không có nghĩa là "chúng tôi không sử dụng chúng trong sự phát triển bình thường" khi tôi nói những "hàng rào thêm gì trong thực tế".

Ý tôi là, ngay cả khi không có những phương pháp này trong Không an toàn, chúng tôi có thể nhận được các "hàng rào" này. Nếu tôi đúng, trên thực tế, đọc một biến động giả có hiệu ứng của loadFence(), và viết một biến động giả có tác dụng của fullFence(), và unsafe.putOrderedXXX() (hoặc AtomicInteger.lazySet()) có hiệu ứng của storeFence().

Chúng có thể có sự khác biệt tinh tế, nhưng trong triển khai hiện tại, chúng có thể trao đổi. (Dường như ngụ ý bởi liên kết)

Đó là ý của tôi "chúng không thêm gì mới".

KHÁC EDIT

này đã được cố định.

Xem https://bugs.openjdk.java.net/browse/JDK-8038978

Cảm ơn @ john-Vint

+0

An [thực hiện liên kết] (http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/50fdb38839eb/src /share/vm/opto/library_call.cpp#l3102) có thể hữu ích. –

Trả lời

6

Thực sự có sự khác biệt về điều này trong JDK9. Có những câu hỏi tương tự đã được hỏi và làm rõ:

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/84e19392365e

 /** 
!  * Ensures that loads before the fence will not be reordered with loads and 
!  * stores after the fence; a "LoadLoad plus LoadStore barrier". 
!  * 
!  * Corresponds to C11 atomic_thread_fence(memory_order_acquire) 
!  * (an "acquire fence"). 
!  * 
!  * A pure LoadLoad fence is not provided, since the addition of LoadStore 
!  * is almost always desired, and most current hardware instructions that 
!  * provide a LoadLoad barrier also provide a LoadStore barrier for free. 
     * @since 1.8 
     */ 
     public native void loadFence(); 

     /** 
!  * Ensures that loads and stores before the fence will not be reordered with 
!  * stores after the fence; a "StoreStore plus LoadStore barrier". 
!  * 
!  * Corresponds to C11 atomic_thread_fence(memory_order_release) 
!  * (a "release fence"). 
!  * 
!  * A pure StoreStore fence is not provided, since the addition of LoadStore 
!  * is almost always desired, and most current hardware instructions that 
!  * provide a StoreStore barrier also provide a LoadStore barrier for free. 
     * @since 1.8 
     */ 
     public native void storeFence(); 

     /** 
!  * Ensures that loads and stores before the fence will not be reordered 
!  * with loads and stores after the fence. Implies the effects of both 
!  * loadFence() and storeFence(), and in addition, the effect of a StoreLoad 
!  * barrier. 
!  * 
!  * Corresponds to C11 atomic_thread_fence(memory_order_seq_cst). 
     * @since 1.8 
     */ 
     public native void fullFence(); 
+1

Vì vậy, nó đã được làm rõ. Tôi cảm thấy một chút ngạc nhiên khi họ bận tâm để thêm rất nhiều từ, với điều kiện Java 9 được cho là làm cho các API nội bộ không sử dụng được. – ntysdd

+0

Những hàng rào này chỉ ngăn cản sắp xếp lại các lần đọc và ghi hay chúng cũng làm cạn kiệt bộ đệm tải/lưu trữ? – CaptainHastings

+0

Chúng được sử dụng chủ yếu để sắp xếp lại và JMM/CPU không phải rút bộ đệm. Ví dụ, nếu bạn đặt 'fullFence' trước và sau khi ghi trong khi thêm' loadFence' trước và sau khi đọc tới biến được viết, bạn vẫn có thể quan sát các lần đọc cũ. –

0

Tôi tin rằng các phương pháp này thêm gần như không có gì trong thực tế.

Đúng, họ sẽ không thêm bất kỳ thứ gì trong 99,9% đơn đăng ký. Chỉ cần trong những trường hợp rất cụ thể, bạn cần gọi phương thức này trực tiếp thay vì sử dụng cấu trúc mức cao hơn.

biến động đọc, ghi lười biếng và ghi biến động tương ứng,

tôi đọc nó như là "không ổn định đọc, ghi ổn định, ghi ổn định và đọc" Có không xuất hiện như một lười biếng/ra lệnh write hàng rào.

loadFence() là một hàng rào có được, và storeFence() là một hàng rào phát hành,

Tôi không tin những dịch để một ngữ nghĩa Acquire/release. Chúng cơ bản hơn thế. Ví dụ, không có sự thay đổi trạng thái trong các phương thức này. có được/phát hành yêu cầu một hoạt động nguyên tử như một compareAndSet, đó là một phương pháp khác không an toàn.

+0

Tôi có nghĩa là một cái gì đó như "AtomicInteger.lazySet()" khi tôi nói lười biếng viết – ntysdd

+0

Tôi không hiểu lý do tại sao bạn nói rằng họ không dịch để có được/phát hành ngữ nghĩa. Tài liệu cho loadFence() nói "Đảm bảo thiếu sắp xếp lại các tải trọng trước hàng rào với tải hoặc cửa hàng sau hàng rào.", Điều đó gần như là định nghĩa của một rào cản có được. – ntysdd

+0

@ntysdd ý của bạn là "có rào cản"? Những thứ này không đọc hay viết nên nó thu thập hay phát hành cái gì? Tôi cho rằng bạn không nói về Semaphore.acquire/release. –

Các vấn đề liên quan