Thread.Sleep (1) mất nhiều hơn 1ms

Question

Tôi đã tìm kiếm câu hỏi này nhưng không thấy câu trả lời. Nếu nó là một bản sao tôi sẽ sẵn sàng đóng nó lại.

Tôi hiện đang cố gắng thực hiện một số đánh giá hiệu suất về công nghệ và thấy một số kết quả không thể tin được vì vậy tôi đã quyết định thử nghiệm một số. Trong đó tôi muốn thử xem liệu lớp Đồng hồ bấm giờ có trả lại những gì tôi mong đợi không.

Stopwatch sw = Stopwatch.StartNew(); 
Thread.Sleep(1); 
sw.Stop(); 
Console.WriteLine(sw.ElapsedMilliseconds); 

Trong trường hợp này, tôi thấy khá nhiều giá trị trả về là 15ms. Tôi hiểu độ phân giải của DateTime để được xung quanh có nhưng không nên Thread.Sleep (1) ngủ một sợi cho 1ms? Hệ thống tôi đang trả về Stopwatch.IsHighResolution đúng và hoạt động của nó trong .NET 4.

Bối cảnh: Biểu mẫu đầy đủ và phù hợp này nhằm thu thập một số số trên yêu cầu nhận được Aerospike db. DB không nằm trên cùng một hộp. Khi tôi in ra các sw.ElapsedMilliseconds khi một truy vấn ở giữa tôi nhìn thấy hầu hết các phản ứng phụ millisecond và có vẻ nghi ngờ một chút xem xét mã Java tương đương của tôi là trở lại nhiều hơn đáng tin cậy 5ms-15ms phản ứng hầu hết thời gian. Mã Java đang sử dụng sự khác biệt của System.nanoTime(). Bởi phản ứng submilli trong mã C# của tôi, tôi có nghĩa là Console.WriteLine (sw.ElapsedMilliseconds) in 0.

Answer 1

Bộ hẹn giờ khác hơn Đồng hồ bấm giờ được tăng thêm bởi ngắt đồng hồ. Mà theo mặc định ticks 64 lần mỗi giây trên Windows. Hoặc 15.625 mili giây. Vì vậy, một đối số Thread.Sleep() nhỏ hơn 16 không cung cấp cho bạn sự chậm trễ mà bạn đang tìm kiếm, bạn sẽ luôn nhận được ít nhất khoảng 15.625 đó. Tương tự, nếu bạn đọc, ví dụ: Environment.TickCount hoặc DateTime.Now và đợi ít hơn hơn 16 mili giây thì bạn sẽ đọc lại cùng một giá trị và nghĩ rằng 0 msec đã trôi qua.

Luôn sử dụng Đồng hồ bấm giờ để đo số gia tăng nhỏ, nó sử dụng nguồn tần số khác. Độ phân giải của nó thay đổi, nó phụ thuộc vào chipset trên bo mạch chủ. Nhưng bạn có thể dựa vào nó tốt hơn một micro giây. Stopwatch.Frequency cung cấp cho bạn tốc độ.

Tốc độ ngắt đồng hồ có thể được thay đổi, bạn phải ghim timeBeginPeriod(). Điều đó có thể giúp bạn giảm xuống một phần nghìn giây và thực sự làm cho Thread.Sleep (1) chính xác. Tốt nhất không làm điều này, nó là rất sức mạnh không thân thiện.

Answer 2

Thread.Sleep (n) có nghĩa là chặn luồng hiện tại cho ít nhất số lần timelices (hoặc số lượng luồng) có thể xảy ra trong vòng mili giây. Độ dài của một timeslice là khác nhau trên các phiên bản khác nhau/các loại Windows và bộ xử lý khác nhau và thường khoảng từ 15 đến 30 mili giây. Điều này có nghĩa là chủ đề gần như được đảm bảo để chặn hơn n mili giây. Khả năng chủ đề của bạn sẽ được đánh thức lại chính xác sau khi n mili giây là không thể thực hiện được. Vì vậy, Thread.Sleep là vô nghĩa cho thời gian.

Answer 3

Thread.Sleep(1) sẽ đặt một chủ đề để ngủ trong 1ms, nhưng bạn thường không thể có được độ chính xác đó.

Tuy nhiên, khi chuỗi đi vào trạng thái ngủ, cần có thời gian để hạt nhân đưa nó trở lại hàng đợi sẵn sàng và sau đó đặt nó vào trạng thái hoạt động khi chuỗi thực sự sẽ chạy lại.

Tất cả các yếu tố này phụ thuộc vào nền tảng, số lượng CPU, số lượng các quy trình khác, v.v. Với hệ điều hành không phải RT, bạn không thể đảm bảo về điều này.

Answer 4

Có những gì bạn đã tìm ra là hoàn toàn chính xác.

Thread.Sleep không đảm bảo phát hành ở N mili giây. Nó sẽ đảm bảo rằng Sleep sẽ không phát hành trước N mili giây.

Nói cách khác Thread.Sleep(1) có nghĩa là Giấc ngủ trong ít nhất 1 mili giây. Hệ điều hành sẽ không lập lịch trình lát thời gian cho một chuỗi cụ thể cho một lượng thời gian cụ thể.

Chủ đề sẽ không được hệ thống điều hành thực hiện trong khoảng thời gian được chỉ định. Phương pháp này thay đổi trạng thái của luồng để bao gồm WaitSleepJoin.

Từ Msdn

Answer 5

Tôi hy vọng rằng Thread.Sleep là gì khác hơn là một wrapper quản lý xung quanh Win32 API Sleep. Người ta biết rằng hàm API này có độ phân giải thấp.Tài liệu nói điều này:

Hàm này làm cho một chuỗi từ bỏ phần còn lại của lát thời gian và không thể khởi động trong một khoảng thời gian dựa trên giá trị của dwMilli giây. Đồng hồ hệ thống "tick" với tốc độ không đổi. Nếu dwMilliseconds nhỏ hơn độ phân giải của đồng hồ hệ thống, luồng có thể ngủ ít hơn khoảng thời gian đã chỉ định. Nếu dwMilliseconds lớn hơn một đánh dấu nhưng nhỏ hơn hai, thì sự chờ đợi có thể ở bất kỳ đâu giữa một và hai dấu tích, v.v. Để tăng độ chính xác của khoảng thời gian ngủ, hãy gọi hàm timeGetDevCaps để xác định độ phân giải hẹn giờ tối thiểu được hỗ trợ và chức năng timeBeginPeriod để đặt độ phân giải bộ hẹn giờ ở mức tối thiểu. Hãy thận trọng khi gọi timeBeginPeriod, vì các cuộc gọi thường xuyên có thể ảnh hưởng đáng kể đến đồng hồ hệ thống, mức sử dụng nguồn hệ thống và trình lên lịch. Nếu bạn gọi timeBeginPeriod, hãy gọi nó sớm một lần trong ứng dụng và chắc chắn gọi hàm timeEndPeriod ở cuối ứng dụng.

Sau khi khoảng thời gian ngủ trôi qua, chuỗi đã sẵn sàng để chạy. Nếu bạn chỉ định 0 mili giây, chuỗi sẽ từ bỏ phần còn lại của lát thời gian của nó nhưng vẫn sẵn sàng. Lưu ý rằng một chuỗi sẵn sàng không được đảm bảo để chạy ngay lập tức. Do đó, luồng có thể không chạy cho đến một thời gian sau khi khoảng thời gian ngủ trôi qua. Để biết thêm thông tin, hãy xem Ưu tiên lập lịch biểu.

Vì vậy, bạn có thể sử dụng timeBeginPeriod và timeEndPeriod làm đề xuất để tăng độ phân giải hẹn giờ, nhưng điều đó thực sự không được khuyến khích. Nếu bạn thực sự cần chặn trong một khoảng thời gian ngắn thì tôi khuyên bạn nên tìm một giải pháp tốt hơn. Ví dụ: bộ hẹn giờ đa phương tiện.

Answer 6

Tìm kiếm "độ phân giải ngủ chủ đề" sẽ trả về những SO câu hỏi liên quan:

• Can I improve the resolution of Thread.Sleep?
• What is the impact of Thread.Sleep(1) in C#?
• Problems with using Thread.Sleep for short times

Đồng thuận được rằng theo mặc định, Sleep() mất ít ít nhất 15ms, trừ khi bạn đặt độ phân giải bằng timeBegin/EndPeriod() như trong answer này.