2013-02-17 21 views
5

Tôi chỉ đọc dòng khó hiểu này trong Peter Richtie blog và tôi cần sự giúp đỡ để hiểu được ý nghĩa Prior to .NET 4.5 you really programmed to the .NET memory model: http://msmvps.com/blogs/peterritchie/archive/2012/09/09/thread-synchronization-of-atomic-invariants-in-net-4-5.aspxĐiều gì đã thay đổi trong mô hình bộ nhớ trong .NET 4.5?

Có mô hình bộ nhớ 'bình thường' NET(chẳng hạn như một thảo luận trong Jeffrey Richter cuốn sách CLR qua C# edition 1 và 2 (Tôi chưa đọc 3d)) thay đổi trong .NET 4.5?

Có bài viết nào có giải thích có ý thức không?

Trả lời

2

Cách thích hợp để xử lý đồng thời trong .NET dựa trên mô hình bộ nhớ yếu. Điều này đã không thay đổi trong .NET 4.5.

Chỉ vì Itanium không còn được hỗ trợ không có nghĩa là bạn có thể giả định các mô hình bộ nhớ x86 hoặc amd64 mạnh hơn. Ví dụ, bạn có các nền tảng mô hình bộ nhớ yếu khác, chẳng hạn như ARM. Luôn luôn nhớ rằng đọc không dễ bay hơi đến cùng một biến hoặc trường có thể được elided sau lần đầu tiên bởi trình biên dịch JIT, trong trường hợp nó có thể chứng minh không có đồng bộ hóa giữa lần đọc (rào cản bộ nhớ, khóa màn hình của một đối tượng là/được theo dõi mở khóa, đọc dễ bay hơi của một biến được viết dễ bay hơi, hoạt động Interlocked trên một biến). Điều này tôn trọng quan điểm nhất quán của luồng.

Bài viết bạn đã liên kết để hiển thị các ví dụ trong đó trình biên dịch JIT của Microsoft .NET Framework đọc sách, ví dụ: while các vòng lặp đọc biến không biến đổi mà không có bất kỳ điểm đồng bộ nào bên trong vòng lặp. Nhưng hãy nhớ, một trình biên dịch JIT có thể sử dụng tối ưu hóa toàn bộ chương trình để khái quát hóa sự cắt bỏ này giữa người gọi và callees.

Như vậy, các thuật toán không khóa trong .NET đọc biến hoặc trường không có rào cản bộ nhớ, khóa, ngữ nghĩa dễ bay hơi hoặc hoạt động Interlocked, trên tiền đề rằng những lần đọc này cuối cùng sẽ thấy thay đổi từ các chủ đề khác Trình biên dịch JIT. Về bản chất, các thuật toán này sai về tính di động.

Điều gì khiến tôi tự hỏi, tại sao bạn lại hỏi điều này?

+0

chúng tôi sống trong các vũ trụ khác nhau. nó trả tiền để biết ở đây .. có lẽ nó trả tiền để viết các ứng dụng di động trong .NET trong vũ trụ của bạn .. Tôi không bận tâm với nó .. là bạn? –

+0

Tôi mong đợi một số thư viện .NET của tôi (được chia sẻ giữa các mục tiêu khác nhau) để hoạt động bình thường trong 32-bit và 64-bit và trong các mô hình bộ nhớ mạnh và các mô hình bộ nhớ yếu. Tôi thậm chí không xem xét tính di động bên ngoài nền tảng của Microsoft. Ví dụ, một số gói NuGet phổ biến nhất hiện nay (Json.NET, NLog) hoạt động trong cả Windows Server 2012 R2 (amd64) và Windows Phone 8.1 hoặc Windows 10 Mobile (có thể là ARM). Điều gì sẽ xảy ra nếu các tác giả không quan tâm đến tính di động? Nó không phải là khó khăn để có được đồng thời đúng, những gì khó khăn là ví dụ để tối ưu hóa, mã refactor để tránh tranh chấp khóa, vv – acelent

+0

Tôi hiểu rằng, từ quan điểm của bạn, bạn có thể cắn viên đạn. Cá nhân, tôi thích có mã sẵn sàng cho mô hình bộ nhớ yếu hơn. Ví dụ, tôi bắt đầu sử dụng các khóa để thực hiện đúng, sau đó lặp lại các trường biến động và/hoặc các hoạt động 'Interlocked'. Nếu bạn quyết định đi với những lần đọc không có bảo vệ, ít nhất hãy làm như vậy một cách cố ý rằng "Nó hoạt động trên máy của bạn (s)". – acelent

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