2010-05-28 79 views
3

我有一個數據轉儲的文件,有不同的時間戳可用的數據,我從時間戳和睡眠我的c線程那段時間。但問題是實際的時間差是10秒,而我在接收端收到的數據差不多是14,15秒延遲。我正在使用窗口操作系統。請引導我。睡眠函數錯誤在C

對不起本週英語。

+1

不理解你的問題......「睡覺我的c線程」? 爲什麼? – Vimard 2010-05-28 08:02:25

+1

如果您認爲無法有效地傳達您的問題,請發佈您正在使用的代碼。這可以幫助他人理解您的問題。 – Jujjuru 2010-05-28 08:06:21

+0

我有一個時間戳數據序列,我必須保持這個序列,以便我想睡覺我的線程。 – Siddiqui 2010-05-28 09:00:00

回答

2

如果我沒有理解好:

  • 你有發送數據的線程
  • 您在使用睡眠
  • 接收到的數據減慢發送節奏(通過網絡什麼是數據的來源?) (在網絡的另一端)可如果上面的介紹,你在做什麼延遲等等(15秒而不是10秒的)

,你的設計有幾個缺陷:

  • 睡眠非常不準確,它會至少等待n秒,但可能會更多(尤其是如果您的系統由其他正在運行的應用程序加載)。
  • 網絡引入了緩衝延遲,您不能保證您的數據將立即通過網絡發送(通常不會)。
  • 旅程本身會引入一些延遲(延遲),如果您的協議等待來自接收端的ACK,則應考慮此問題。
  • 你還應該考慮讀取/建立/檢索數據發送所需的時間,並確實通過線路發送數據。根據你在做什麼,它可以忽略不計或需要幾秒鐘...

如果您提供一些更多的細節,將更容易診斷問題的根源。 sleep,因爲你相信(它確實是一個非常糟糕的計時器)或你係統的其他部分。

如果你的轉儲很大,我會打賭,額外的時間來自讀取數據並通過電線發送。您應該確定發送過程中消耗的時間(讀完發送前後的時間)。

如果這確實是額外時間的來源,那麼您只需要從下次等待時間中刪除該時間。

示例:發送前一個數據塊需要4s,下一個數據塊是10s後,但是當您已經使用4s時,您只需等待6s。

sleep仍然是一個相當不精確的計時器,如果發送時間大於發送之間的延遲,上述機制顯然不起作用,但您明白了。

更正睡眠在windows環境中並不像它在unixes中那麼糟糕。 windows的睡眠準確度是毫秒,unix睡眠的準確率是次之。如果你不需要高精度定時(並且如果涉及網絡,則無論如何高精度定時都是遙不可及的)睡眠應該沒問題。

+0

數據來源是我的轉儲txt文件。 – Siddiqui 2010-05-28 09:03:02

3

睡眠功能將至少與您指定的時間一樣長的睡眠時間,但不能保證睡眠時間不會更長。如果您需要準確的時間間隔,則需要使用其他一些機制。

+0

請在窗口操作系統上給我一些準確的睡眠方向。 – Siddiqui 2010-05-28 09:01:05

+0

考慮到@Arman正在使用Windows,因爲Windows不是實時操作系統,所以在精確的時間間隔內很難休眠。 – 2010-05-28 13:36:37

1

任何現代多任務操作系統的調度程序不會保證任何用戶應用程序的任何確切時間。 您可以嘗試以某種方式爲您的應用程序分配「實時」優先級,例如從Windows任務管理器。看看它是否有幫助。

另一種解決方案是實施'受控'睡眠,即睡眠一系列500ms,檢查它們之間的當前時間戳。所以,如果你的所有人都會在某個步驟中睡1s而不是500ms - 你會注意到它,而不是額外的睡眠(500ms)。

0

試用一個Multimedia Timer。它與您在Windows系統上可以獲得的準確性大致相同。 CodeProject上有一個關於它們的好article

0

睡眠功能可能需要比所需時間更長的時間,但從不會更少。使用winapi定時器函數從現在開始在一段時間內得到一個叫回的函數。

您也可以使用Windows任務計劃程序,但這是超出了程序化的獨立選項。