2015-10-01 14 views
5

Tôi đang ở giai đoạn nâng cấp một số mã C++ cũ lên C++ 11 trong Linux bằng gcc. Khi cố gắng đặt ưu tiên, tôi đã đưa ra câu hỏi sau. Có thể có bất kỳ lợi thế nào trong việc trao đổi cuộc gọi đến usleep với một cuộc gọi đến std::this_thread::sleep_for không? Trong mã tôi đang nói về thread đang chạy được cho là phải đợi trong một khoảng thời gian rất ngắn. Do đó tôi không cần bất kỳ tính năng nâng cao nào như làm gián đoạn giấc ngủ.Tôi có nên đổi ngủ với sleep_for

+0

Có, nó sẽ cải thiện tính di động của mã. –

+0

Mỗi khi bạn thay đổi mã, bạn có nguy cơ giới thiệu một lỗi như vậy, nếu nó 'aint đã phá vỡ không sửa chữa nó. Tuy nhiên, nếu bạn đang sửa chữa các chức năng anyways lý do tại sao không di chuyển đến xách tay hơn, mã tiêu chuẩn? – Galik

Trả lời

9

Có. std::this_thread::sleep_for được chỉ định theo tiêu chuẩn C++ 11, và do đó là giải pháp di động trên bất kỳ hệ thống nào có trình biên dịch C++ 11 và thư viện chuẩn.

usleep được chỉ định bởi POSIX.1-2001 (và tuyên bố lỗi thời!), Có nghĩa là nó chỉ có thể được (đáng tin cậy) được sử dụng trên các hệ thống tuân thủ POSIX.

POSIX.1-2008 loại bỏ đặc điểm kỹ thuật của usleep, có lợi cho nanosleep. Vì lý do này một mình, std::this_thread::sleep_for là một sự lựa chọn tốt hơn nhiều.

(Xem http://linux.die.net/man/3/usleep để biết chi tiết).

+0

Tôi hiểu rằng tôi nên sử dụng các chức năng tuân thủ tiêu chuẩn hơn các chức năng POSIX. Nhưng tôi có nên mong đợi bất kỳ tác dụng phụ nào không? Có thể sleep_for cư xử khác với giấc ngủ? Có thể có lợi ích hoặc hình phạt về hiệu suất không? –

+0

Không xa như tôi có thể thấy. Cả hai được quy định để ngủ cho _at ít nhất_ thời gian quy định (tức là nó có thể dài hơn, tùy thuộc vào lịch trình, vv) – Andrew

+0

Đối với mối quan tâm về hiệu suất, quá trình hành động hợp lý duy nhất là _profile_ hai giải pháp. Tôi không thể tưởng tượng có sự khác biệt đáng kể giữa hai người; không được so sánh với thời gian chờ đợi. – Andrew

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