Dễ bay hơi so với khóa liên động so với khóa

Giả sử một lớp có một public int countertrường được truy cập bởi nhiều luồng. Điều này intchỉ tăng hoặc giảm.

Để tăng lĩnh vực này, nên sử dụng phương pháp nào, và tại sao?

• lock(this.locker) this.counter++;,
• Interlocked.Increment(ref this.counter);,
• Thay đổi công cụ sửa đổi truy cập counterthành public volatile.

Bây giờ tôi đã phát hiện ra volatile, tôi đã loại bỏ nhiều locktuyên bố và việc sử dụng Interlocked. Nhưng có một lý do để không làm điều này?

Tệ nhất (sẽ không thực sự hoạt động)

Thay đổi modifier tiếp cận của counterđểpublic volatile

Như những người khác đã đề cập, điều này tự nó không thực sự an toàn. Điểm chính volatilelà nhiều luồng chạy trên nhiều CPU có thể và sẽ lưu trữ dữ liệu và hướng dẫn lại thứ tự.

Nếu không volatile , và CPU A tăng một giá trị, thì CPU B có thể không thực sự thấy giá trị tăng đó cho đến một lúc sau, điều này có thể gây ra sự cố.

Nếu có volatile, điều này chỉ đảm bảo hai CPU nhìn thấy cùng một dữ liệu cùng một lúc. Điều đó hoàn toàn không ngăn cản họ xen kẽ các hoạt động đọc và ghi của họ, đây là vấn đề bạn đang cố gắng tránh.

Tốt thứ hai:

lock(this.locker) this.counter++;

Điều này là an toàn để làm (miễn là bạn nhớ đến lockmọi nơi khác mà bạn truy cập this.counter). Nó ngăn chặn bất kỳ luồng nào khác thực thi bất kỳ mã nào khác được bảo vệ bởi locker. Cũng sử dụng khóa, ngăn chặn các vấn đề sắp xếp lại đa CPU như trên, điều này thật tuyệt vời.

Vấn đề là, khóa rất chậm và nếu bạn sử dụng lại lockerở một nơi khác không thực sự liên quan thì cuối cùng bạn có thể chặn các luồng khác mà không có lý do.

Tốt

Interlocked.Increment(ref this.counter);

Điều này là an toàn, vì nó thực sự đọc, tăng và viết trong 'một lần nhấn' mà không thể bị gián đoạn. Vì điều này, nó sẽ không ảnh hưởng đến bất kỳ mã nào khác và bạn cũng không cần phải nhớ khóa ở nơi khác. Nó cũng rất nhanh (như MSDN nói, trên các CPU hiện đại, đây thường chỉ là một lệnh CPU).

Tuy nhiên, tôi không hoàn toàn chắc chắn nếu nó xoay quanh các CPU khác sắp xếp lại mọi thứ hoặc nếu bạn cũng cần kết hợp dễ bay hơi với mức tăng.

Liên khóa:

1. CÁC PHƯƠNG PHÁP GIẢI QUYẾT ĐƯỢC AN TOÀN AN TOÀN TRÊN MỌI SỐ L CORI HOẶC CPU.
2. Các phương thức lồng vào nhau áp dụng một hàng rào đầy đủ xung quanh các hướng dẫn mà chúng thực hiện, do đó việc sắp xếp lại không xảy ra.
3. Các phương thức lồng vào nhau không cần hoặc thậm chí không hỗ trợ truy cập vào trường dễ bay hơi , vì dễ bay hơi được đặt một nửa hàng rào xung quanh các hoạt động trên trường đã cho và lồng vào nhau là sử dụng toàn bộ hàng rào.

Lưu ý: Những gì dễ bay hơi thực sự tốt cho.

Vì volatilekhông ngăn được các loại vấn đề đa luồng này, nó dùng để làm gì? Một ví dụ điển hình là bạn có hai luồng, một luồng luôn ghi vào một biến (nói queueLength) và một luồng luôn đọc từ cùng một biến đó.

Nếu queueLengthkhông dễ bay hơi, luồng A có thể viết năm lần, nhưng luồng B có thể thấy những lần ghi đó bị trì hoãn (hoặc thậm chí có khả năng sai thứ tự).

Một giải pháp sẽ là khóa, nhưng bạn cũng có thể sử dụng dễ bay hơi trong tình huống này. Điều này sẽ đảm bảo rằng chủ đề B sẽ luôn nhìn thấy điều cập nhật nhất mà chủ đề A đã viết. Tuy nhiên, lưu ý rằng logic này chỉ hoạt động nếu bạn có nhà văn không bao giờ đọc và độc giả không bao giờ viết và nếu điều bạn đang viết là một giá trị nguyên tử. Ngay sau khi bạn thực hiện một lần đọc-sửa đổi-ghi, bạn cần chuyển đến các hoạt động lồng vào nhau hoặc sử dụng Khóa.

EDIT: Như đã lưu ý trong các bình luận, ngày nay tôi rất vui khi sử dụng Interlockedcho các trường hợp của một biến duy nhất trong đó rõ ràng là ổn. Khi nó trở nên phức tạp hơn, tôi vẫn sẽ quay lại khóa ...

Sử dụng volatilesẽ không giúp ích khi bạn cần tăng - bởi vì đọc và viết là các hướng dẫn riêng biệt. Một chủ đề khác có thể thay đổi giá trị sau khi bạn đọc nhưng trước khi bạn viết lại.

Cá nhân tôi hầu như luôn luôn khóa - dễ dàng hơn để đi đúng theo cách rõ ràng là đúng hơn là biến động hoặc Liên khóa. Theo như tôi quan tâm, đa luồng không khóa là dành cho các chuyên gia luồng thực sự, trong đó tôi không phải là một. Nếu Joe Duffy và nhóm của anh ấy xây dựng những thư viện đẹp, sẽ song song mọi thứ mà không bị khóa nhiều như thứ tôi xây, thì thật tuyệt vời, và tôi sẽ sử dụng nó trong tích tắc - nhưng khi tôi tự mình xâu chuỗi, tôi sẽ cố gắng giữ cho nó đơn giản

" volatile" không thay thế Interlocked.Increment! Nó chỉ đảm bảo rằng biến không được lưu trong bộ nhớ cache, nhưng được sử dụng trực tiếp.

Tăng một biến đòi hỏi thực sự ba thao tác:

1. đọc
2. tăng
3. viết

Interlocked.Increment thực hiện cả ba phần như một hoạt động nguyên tử duy nhất.

Khóa hoặc gia tăng lồng vào nhau là những gì bạn đang tìm kiếm.

Tính dễ bay hơi chắc chắn không phải là thứ bạn đang theo đuổi - nó chỉ đơn giản là yêu cầu trình biên dịch coi biến luôn luôn thay đổi ngay cả khi đường dẫn mã hiện tại cho phép trình biên dịch tối ưu hóa việc đọc từ bộ nhớ.

ví dụ

while (m_Var)
{ }

nếu m_Var được đặt thành false trong một luồng khác nhưng nó không được khai báo là không ổn định, trình biên dịch sẽ tự do biến nó thành một vòng lặp vô hạn (nhưng không có nghĩa là nó sẽ luôn như vậy) bằng cách kiểm tra nó đối với thanh ghi CPU (ví dụ EAX vì đó là những gì m_Var đã được tải xuống ngay từ đầu) thay vì phát hành một lần đọc khác vào vị trí bộ nhớ của m_Var (điều này có thể được lưu trong bộ nhớ cache - chúng tôi không biết và không quan tâm và đó là điểm kết hợp bộ nhớ cache của x86 / x64). Tất cả các bài đăng trước đó bởi những người khác đã đề cập sắp xếp lại hướng dẫn chỉ đơn giản cho thấy họ không hiểu kiến ​​trúc x86 / x64. Dễ bay hơi khôngvấn đề đọc / ghi các rào cản như được ngụ ý bởi các bài viết trước đó nói rằng 'nó ngăn chặn sắp xếp lại'. Trên thực tế, một lần nữa nhờ vào giao thức MESI, chúng tôi được đảm bảo rằng kết quả mà chúng tôi đọc luôn giống nhau trên các CPU bất kể kết quả thực tế đã được đưa vào bộ nhớ vật lý hay chỉ đơn giản là nằm trong bộ đệm của CPU cục bộ. Tôi sẽ không đi quá sâu vào chi tiết về điều này nhưng hãy yên tâm rằng nếu điều này xảy ra, Intel / AMD có thể sẽ đưa ra lệnh thu hồi bộ xử lý! Điều này cũng có nghĩa là chúng tôi không phải quan tâm đến việc thực hiện đơn hàng, v.v. Kết quả luôn được đảm bảo để nghỉ hưu theo thứ tự - nếu không chúng tôi bị nhồi!

Với Gia tăng liên khóa, bộ xử lý cần phải ra ngoài, lấy giá trị từ địa chỉ đã cho, sau đó tăng và ghi lại - tất cả điều đó trong khi có quyền sở hữu độc quyền toàn bộ dòng bộ đệm (khóa xadd) để đảm bảo không có bộ xử lý nào khác có thể sửa đổi Giá trị của nó.

Với tính không ổn định, bạn vẫn sẽ kết thúc chỉ với 1 hướng dẫn (giả sử JIT hoạt động hiệu quả như bình thường) - inc dword ptr [m_Var]. Tuy nhiên, bộ xử lý (cpuA) không yêu cầu quyền sở hữu độc quyền của dòng bộ đệm trong khi thực hiện tất cả những gì đã làm với phiên bản khóa liên động. Như bạn có thể tưởng tượng, điều này có nghĩa là các bộ xử lý khác có thể ghi giá trị cập nhật trở lại m_Var sau khi được cpuA đọc. Vì vậy, thay vì bây giờ đã tăng giá trị hai lần, bạn kết thúc chỉ với một lần.

Hy vọng điều này làm sáng tỏ vấn đề.

Để biết thêm thông tin, hãy xem 'Hiểu tác động của các kỹ thuật khóa thấp trong các ứng dụng đa luồng' - http://msdn.microsoft.com/en-au/magazine/cc163715.aspx

ps Điều gì đã thúc đẩy trả lời rất muộn này? Tất cả các câu trả lời rất không chính xác (đặc biệt là câu trả lời là câu trả lời) trong phần giải thích của họ, tôi chỉ phải làm rõ cho bất kỳ ai khác đọc nó. nhún vai

pps Tôi giả sử rằng mục tiêu là x86 / x64 chứ không phải IA64 (nó có một mô hình bộ nhớ khác). Lưu ý rằng thông số kỹ thuật ECMA của Microsoft bị sai lệch ở chỗ nó chỉ định mô hình bộ nhớ yếu nhất thay vì mô hình bộ nhớ mạnh nhất (tốt hơn là chỉ định theo mô hình bộ nhớ mạnh nhất để phù hợp trên các nền tảng - nếu không thì mã sẽ chạy 24-7 trên x86 / x64 hoàn toàn không thể chạy trên IA64 mặc dù Intel đã triển khai mô hình bộ nhớ mạnh tương tự cho IA64) - Microsoft đã thừa nhận điều này - http://bloss.msdn.com/b/cbrumme/archive/2003/05/17/51445.aspx .

Chức năng lồng vào nhau không khóa. Chúng là nguyên tử, có nghĩa là chúng có thể hoàn thành mà không có khả năng chuyển đổi ngữ cảnh trong quá trình tăng. Vì vậy, không có cơ hội bế tắc hoặc chờ đợi.

Tôi sẽ nói rằng bạn nên luôn luôn thích nó để khóa và tăng.

Volility rất hữu ích nếu bạn cần ghi vào một luồng để đọc trong một luồng khác và nếu bạn muốn trình tối ưu hóa không sắp xếp lại các hoạt động trên một biến (vì mọi thứ đang diễn ra trong một luồng khác mà trình tối ưu hóa không biết). Đó là một lựa chọn trực giao cho cách bạn tăng lên.

Đây là một bài viết thực sự tốt nếu bạn muốn đọc thêm về mã không khóa và cách tiếp cận đúng để viết nó

http://www.ddj.com/hpc-high-performance-computing/210604448

khóa (...) hoạt động, nhưng có thể chặn một luồng và có thể gây ra bế tắc nếu mã khác đang sử dụng cùng một khóa theo cách không tương thích.

Được lồng vào nhau. * Là cách chính xác để làm điều đó ... ít chi phí hơn vì các CPU hiện đại hỗ trợ điều này như một nguyên thủy.

tự nó biến động là không chính xác. Một luồng cố gắng truy xuất và sau đó ghi lại một giá trị đã sửa đổi vẫn có thể xung đột với một luồng khác làm tương tự.

Tôi đã làm một số thử nghiệm để xem lý thuyết thực sự hoạt động như thế nào: kennethxu.blogspot.com/2009/05/interlocked-vs-monitor-performance.html . Thử nghiệm của tôi tập trung nhiều hơn vào so sánhExchnage nhưng kết quả cho Tăng là tương tự. Liên khóa là không cần thiết nhanh hơn trong môi trường đa cpu. Dưới đây là kết quả thử nghiệm cho Tăng trên máy chủ CPU 16 năm tuổi. Nghĩ rằng thử nghiệm cũng liên quan đến việc đọc an toàn sau khi tăng, đó là điển hình trong thế giới thực.

D:\>InterlockVsMonitor.exe 16
Using 16 threads:
          InterlockAtomic.RunIncrement         (ns):   8355 Average,   8302 Minimal,   8409 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):   7077 Average,   6843 Minimal,   7243 Maxmial

D:\>InterlockVsMonitor.exe 4
Using 4 threads:
          InterlockAtomic.RunIncrement         (ns):   4319 Average,   4319 Minimal,   4321 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):    933 Average,    802 Minimal,   1018 Maxmial

Tôi thứ hai câu trả lời của Jon Skeet và muốn thêm các liên kết sau cho tất cả những ai muốn biết thêm về "dễ bay hơi" và Liên khóa:

Tính nguyên tử, tính dễ bay hơi và tính bất biến là khác nhau, phần một - (Cuộc phiêu lưu tuyệt vời trong mã hóa của Eric Lippert)

Nguyên tử, biến động và bất biến là khác nhau, phần hai

Tính nguyên tử, tính dễ bay hơi và tính bất biến là khác nhau, phần ba

Sayonara dễ bay hơi - (Ảnh chụp lại máy Wayback của Weblog của Joe Duffy khi nó xuất hiện vào năm 2012)

Tôi muốn thêm vào được đề cập trong câu trả lời khác chênh lệch giữa volatile, Interlockedvà lock:

Từ khóa dễ bay hơi có thể được áp dụng cho các trường thuộc các loại sau:

• Các loại tham khảo.
• Các loại con trỏ (trong một bối cảnh không an toàn). Lưu ý rằng mặc dù con trỏ có thể không ổn định, nhưng đối tượng mà nó trỏ đến không thể. Nói cách khác, bạn không thể khai báo "con trỏ" là "dễ bay hơi".
• Loại đơn giản như sbyte, byte, short, ushort, int, uint, char, float, và bool.
• Một kiểu enum với một trong những loại cơ sở sau: byte, sbyte, short, ushort, inthoặc uint.
• Các tham số loại chung được biết đến là các loại tham chiếu.
• IntPtrvà UIntPtr.

Các loại khác , bao gồm doublevà long, không thể được đánh dấu là "dễ bay hơi" vì đọc và ghi vào các trường của các loại đó không thể được đảm bảo là nguyên tử. Để bảo vệ quyền truy cập đa luồng vào các loại trường đó, hãy sử dụng các Interlockedthành viên lớp hoặc bảo vệ quyền truy cập bằng cách sử dụng lockcâu lệnh.