Câu lệnh khóa đắt như thế nào?

Tôi đã thử nghiệm với xử lý đa luồng và song song và tôi cần một bộ đếm để thực hiện một số phân tích thống kê và đếm cơ bản về tốc độ xử lý. Để tránh các vấn đề với việc sử dụng đồng thời lớp của tôi, tôi đã sử dụng câu lệnh khóa trên một biến riêng trong lớp của mình:

private object mutex = new object();

public void Count(int amount)
{
 lock(mutex)
 {
  done += amount;
 }
}

Nhưng tôi đã tự hỏi ... làm thế nào đắt là khóa một biến? Những tác động tiêu cực đến hiệu suất là gì?

Đây là một bài báo đi vào chi phí. Câu trả lời ngắn gọn là 50ns.

Câu trả lời kỹ thuật là không thể định lượng được điều này, nó phụ thuộc nhiều vào trạng thái của bộ đệm ghi ngược bộ nhớ CPU và lượng dữ liệu mà trình cài đặt sẵn thu thập được phải được loại bỏ và đọc lại. Cả hai đều rất không xác định. Tôi sử dụng 150 chu kỳ CPU như một phép xấp xỉ phía sau để tránh những thất vọng lớn.

Câu trả lời thực tế là nó là waaaay rẻ hơn so với số lượng thời gian bạn sẽ ghi vào gỡ lỗi mã của bạn khi bạn nghĩ rằng bạn có thể bỏ qua một khóa.

Để có được một con số khó, bạn sẽ phải đo lường. Visual Studio có một trình phân tích đồng thời mượt mà có sẵn dưới dạng tiện ích mở rộng.

Đọc thêm:

Tôi muốn trình bày một số bài báo của tôi, quan tâm đến các nguyên thủy đồng bộ hóa chung và họ đang đào sâu vào hành vi, thuộc tính và chi phí của câu lệnh khóa Monitor, C # tùy thuộc vào các kịch bản và số lượng luồng riêng biệt. Nó đặc biệt quan tâm đến thời gian lãng phí CPU và thông lượng để hiểu mức độ công việc có thể được đẩy qua trong nhiều trường hợp:

https://www.codeproject.com/Articles/1236238/Unified-Concurrency-I-Introduction https://www.codeproject.com/Articles/1237518/Unified-Concurrency-II-benchmarking-methodologies https: // www. codeproject.com/Articles/1242156/Unified-Concurrency-III-cross-benchmarking

Câu trả lời ban đầu:

Ôi chao!

Có vẻ như câu trả lời đúng được gắn cờ ở đây là CÂU TRẢ LỜI vốn dĩ không chính xác! Em xin tác giả câu trả lời, kính mong anh chị đọc bài đã liên kết đến cuối. bài báo

Tác giả của bài báo từ năm 2003 bài viết được đo trên chỉ máy Dual Core và trong trường hợp đo đầu tiên, ông đo khóa với chỉ một chủ đề duy nhất và kết quả là khoảng 50ns mỗi truy cập khóa.

Nó không nói gì về một khóa trong môi trường đồng thời. Vì vậy, chúng ta phải tiếp tục đọc bài báo và trong nửa sau, tác giả đã đo lường kịch bản khóa với hai và ba luồng, tiến gần hơn đến mức đồng thời của các bộ xử lý ngày nay.

Vì vậy, tác giả nói rằng với hai luồng trên Dual Core, các ổ khóa có giá 120ns, và với 3 luồng, nó lên đến 180ns. Vì vậy, nó dường như phụ thuộc rõ ràng vào số lượng luồng truy cập đồng thời vào khóa.

Vì vậy, nó rất đơn giản, nó không phải là 50 ns trừ khi nó là một sợi duy nhất, nơi ổ khóa trở nên vô dụng.

Một vấn đề khác cần xem xét là nó được đo bằng thời gian trung bình !

Nếu thời gian lặp lại được đo, thậm chí sẽ có thời gian từ 1 mili giây đến 20 mili giây, đơn giản vì phần lớn tốc độ nhanh, nhưng một số luồng sẽ đợi thời gian của bộ xử lý và gây ra sự chậm trễ thậm chí là mili giây.

Đây là tin xấu cho bất kỳ loại ứng dụng nào yêu cầu thông lượng cao, độ trễ thấp.

Và vấn đề cuối cùng cần xem xét là có thể có các hoạt động chậm hơn bên trong khóa và rất thường xuyên xảy ra trường hợp đó. Khối mã được thực thi bên trong khóa càng lâu thì sự tranh chấp càng cao và sự chậm trễ sẽ tăng cao.

Vui lòng xem xét, đã hơn một thập kỷ trôi qua kể từ năm 2003, có rất ít thế hệ bộ vi xử lý được thiết kế đặc biệt để chạy hoàn toàn đồng thời và việc khóa có hại đáng kể đến hiệu suất của chúng.

Điều này không trả lời truy vấn của bạn về hiệu suất, nhưng tôi có thể nói rằng .NET Framework cung cấp một Interlocked.Addphương pháp cho phép bạn thêm của bạn amountvào donethành viên của mình mà không cần khóa thủ công trên đối tượng khác.

lock (Monitor.Enter / Exit) rất rẻ, rẻ hơn các lựa chọn thay thế như Waithandle hoặc Mutex.

Nhưng nếu nó chậm (một chút), bạn muốn có một chương trình nhanh với kết quả không chính xác thì sao?

Chi phí cho một khóa trong một vòng lặp chặt chẽ, so với một giải pháp thay thế không có khóa, là rất lớn. Bạn có thể đủ khả năng lặp lại nhiều lần mà vẫn hiệu quả hơn khóa. Đó là lý do tại sao khóa hàng đợi miễn phí lại rất hiệu quả.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace LockPerformanceConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var stopwatch = new Stopwatch();
            const int LoopCount = (int) (100 * 1e6);
            int counter = 0;

            for (int repetition = 0; repetition < 5; repetition++)
            {
                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    lock (stopwatch)
                        counter = i;
                stopwatch.Stop();
                Console.WriteLine("With lock: {0}", stopwatch.ElapsedMilliseconds);

                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    counter = i;
                stopwatch.Stop();
                Console.WriteLine("Without lock: {0}", stopwatch.ElapsedMilliseconds);
            }

            Console.ReadKey();
        }
    }
}

Đầu ra:

With lock: 2013
Without lock: 211
With lock: 2002
Without lock: 210
With lock: 1989
Without lock: 210
With lock: 1987
Without lock: 207
With lock: 1988
Without lock: 208

Có một số cách khác nhau để xác định "chi phí". Có chi phí thực tế của việc lấy và giải phóng khóa; như Jake viết, điều đó không đáng kể trừ khi thao tác này được thực hiện hàng triệu lần.

Mức độ liên quan hơn là ảnh hưởng của điều này đối với luồng thực thi. Mã này chỉ có thể được nhập bởi một chủ đề tại một thời điểm. Nếu bạn có 5 luồng thực hiện thao tác này thường xuyên, thì 4 trong số đó sẽ kết thúc chờ khóa được giải phóng và sau đó là chuỗi đầu tiên được lên lịch để nhập đoạn mã đó sau khi khóa đó được giải phóng. Vì vậy, thuật toán của bạn sẽ bị ảnh hưởng đáng kể. Mức độ phụ thuộc vào thuật toán và tần suất hoạt động được gọi như thế nào .. Bạn thực sự không thể tránh nó mà không đưa ra các điều kiện chủng tộc, nhưng bạn có thể cải thiện nó bằng cách giảm thiểu số lần gọi đến mã bị khóa.