2

以下のコードを使用して、ハンドラー関数を連続して呼び出すたびに経過時間をミリ秒単位で計算しています。usleep（1000）を使用する場合、つまり各呼び出し間の1ミリ秒の時間差は10ミリ秒であり、usleep（1000000）を使用する場合、つまり1秒の場合、各呼び出し間の時間間隔は1ミリ秒未満になります。以下はコードスニペットです：

    #include<stdio.h>
    #include<stdlib.h>
    #include<sys/time.h>
    #include<unistd.h>

    struct timeval start_time;
    void handler(int);

    int main()
    {
            struct timeval current_time;
            int i=0;
            gettimeofday(&start_time,0);
            gettimeofday(&current_time,0);
            printf("%012.3fms: emulationbegins\n",((current_time.tv_usec-start_time.tv_usec)/1000.0));

            while(i++<5)
            {
                    usleep(1000); // compare with usleep(1000000)
                    handler(i);
            }

            return 0;
    }

    void handler(int i)
    {
            printf("In Handler %d\n",i);
            struct timeval current_time;
            gettimeofday(&current_time,0);
            printf("%012.3fms: Handler Called\n",((current_time.tv_usec-start_time.tv_usec)/1000.0));
            return;
    }
4

2 に答える 2

3

tv_usec構造体のフィールドがtimeval100万に達することはなく、秒数が増えることを忘れないでください。

tv_sec計算でもフィールドを使用する必要があります。

于 2013-02-13T11:28:30.753 に答える
2

usleep少なくともあなたが与えた量だけ眠るように指定されていますが、それはずっと長く眠ることができます。実行するより重要なプロセスがある場合、オペレーティングシステムはプロセスを実行する必要がないため、スリープする時間の上限はほとんどありません。

実際には、スリープする時間の解像度はusleep、オペレーティングシステムが使用するクロックによって決まります。数年前まで、ほとんどのUNIXライクなシステムは、静的100Hzタイマー（またはまれなケースでは1024Hz）を使用してこのようなタイマーを駆動していたため、usleepは常に最も近い10msに切り上げられていました。

静的クロックを削除するために最近いくつかのシステムでいくつかの作業が行われていますが、これはより高い解像度のスリープの必要性によってそれほど推進されていませんが、静的クロックティックのためにCPUを常にウェイクアップするという事実によって消費電力に悪い。タイマーの解像度を向上させるという副作用がありますが、非常に短いスリープを使用し、正しく動作しているように見えるアプリケーションのバグが明らかになります。突然、 // usleep/のタイムアウトの解像度が高くなると、これらの短いスリープにより、アプリケーションがCPUでスピンし、常にスリープを再スケジュールすることになります。nanosleeppollselect

今日の状態はわかりませんが、10ミリ秒から、システムは内部タイマーに100Hzのクロックを使用しているように見えます。または、アプリケーションが破損しないように、タイムアウトを意図的に10ミリ秒の解像度に遅くしているようです。

于 2013-02-13T12:08:20.770 に答える