我有一个数据转储文件，有不同的时间戳数据可用，我从时间戳得到的时间，睡觉我的c线程。 但问题是实际的时间差是10秒，而我在接收端收到的数据差不多是14,15秒的延迟。 我正在使用窗口操作系统。 请引导我。
对不起我的一周英语。
如果我理解得好：
如果上面描述你在做什么，你的设计有几个缺陷：
如果您提供更多的细节，将更容易诊断问题的根源。 如你所相信sleep （这确实是一个非常糟糕的计时器）或你的系统的其他部分。
如果你的转储很大，我敢打赌，额外的时间来自读取数据并通过网络发送。 您应该确定发送过程中消耗的时间（发送前后的读取时间）。
如果这确实是额外时间的来源，那么您只需要从下一次等待就消除这个时间。
例如：发送前一个数据块需要4s，下一个数据块是10s后，但是当你已经使用4s时，你只需等待6s。
sleep仍然是一个相当不精确的计时器，显然如果发送时间大于发送之间的延迟，上述机制将不起作用，但您明白了。
在Windows环境中校正睡眠并不像在unix中那样糟糕。 windows的睡眠准确度是毫秒，unix睡眠的准确度是次之。 如果你不需要高精度的时间（如果涉及到网络的话，高精度的时间是无法达到的）睡眠应该没问题。
睡眠功能将至少与您指定的时间一样睡眠，但不能保证睡眠时间不会更长。如果您需要精确的时间间隔，则需要使用其他一些机制。
任何现代的多任务操作系统的调度程序不会保证任何用户应用程序的确切时间。 您可以尝试以某种方式为您的应用程序分配“实时”优先级，例如从Windows任务管理器。 看看是否有帮助
另一种解决方案是实现“受控”的睡眠，即睡眠一系列的500ms，检查它们之间的当前时间戳。 所以，如果你的所有人都会在某一步睡觉1秒而不是500毫秒 – 你会注意到它，而不是额外的睡眠（500毫秒）。
尝试一个多媒体计时器 。 这与您在Windows系统上可以获得的准确性大致相同。 CodeProject上有一篇关于它们的好文章 。
睡眠功能可能需要比所需时间更长的时间，但永远不会少。 使用winapi定时器函数从现在开始在一段时间内得到一个叫回的函数。
您也可以使用Windows任务计划程序，但这不在程序化的独立选项之中。