فهم دقة gettimeofday() في لينكس: هل هي مضمونة أن تكون دقيقة بالميكروثانية؟

عند تطوير تطبيقات تتطلب توقيتًا دقيقًا، مثل الألعاب أو البرمجيات التي تتطلب أداءً عاليًا، يمكن أن يؤثر اختيار وظائف التوقيت بشكل كبير على موثوقية أداء التطبيق. في منشور المدونة هذا، سننظر في سؤال شائع يواجهه المطورون: هل gettimeofday() مضمونة أن تكون بدقة ميكروثانية؟

المشكلة: قابلية النقل ودقة التوقيت

عندما تحاول نقل لعبة من واجهة برمجة التطبيقات Win32 إلى لينكس، قد تصبح دقة قياس الوقت صعبة. تستخدم التنفيذ الأصلي QueryPerformanceCounter الذي يوفر توقيتًا بدقة عالية. في عملية نقل هذه الوظيفة، تلجأ إلى gettimeofday()، التي يمكنها تقديم الوقت بالميكروثانية منذ بداية القرن. ومع ذلك، تريد أن تفهم ما إذا كان استخدام هذه الوظيفة قابلاً للنقل وموثوقًا عبر أنظمة لينكس المختلفة.

التحدي في التنفيذ

في شيفرتك، قمت بتنفيذ الطريقة التالية لاستخدام gettimeofday() لمحاكاة QueryPerformanceCounter:

BOOL QueryPerformanceCounter(LARGE_INTEGER* performanceCount)
{
    gettimeofday(&currentTimeVal, NULL);
    performanceCount->QuadPart = (currentTimeVal.tv_sec - startTimeVal.tv_sec);
    performanceCount->QuadPart *= (1000 * 1000);
    performanceCount->QuadPart += (currentTimeVal.tv_usec - startTimeVal.tv_usec);

    return true;
}

بينما تعطيك هذه الطريقة متغيرًا من 64 بت يحمل الميكروثواني منذ بدء العملية، من الضروري التعمق في قيود gettimeofday().

الحقيقة حول دقة gettimeofday()

غالبًا ما يتم فهم دقة gettimeofday() بشكل خاطئ. يمكن أن توفر هذه الدالة قياسات للوقت، ولكن هناك تحذيرات حاسمة:

• قيود الدقة: على أنظمة لينكس القياسية، عادةً ما تكون دقة gettimeofday() 10 ميكروثانية. هذا يعني أنه رغم أنها قد تقدم قيمًا بالميكروثانية، قد لا تكون الدقة موثوقة.
• تداخل النظام: يمكن أن تتأثر التوقيت بعوامل متنوعة، بما في ذلك:
  • عمليات الخلفية: يمكن أن تؤدي العمليات الخلفية التي تعدل الساعة النظامية إلى القفزات في الوقت.
  • بروتوكول NTP (بروتوكول الوقت الشبكي): إذا تم تكوينه، يمكن أن يعدل NTP الوقت النظامي، مما يؤثر على ناتج gettimeofday().

تؤدي هذه القضايا إلى الاستنتاج أن الجواب على السؤال الأصلي هو لا، لا يمكن الاعتماد على gettimeofday() للحصول على قياسات دقيقة ومتسقة بالميكروثانية عبر جميع الأنظمة.

بديل أفضل: استخدام clock_gettime()

لضمان توقيت أكثر موثوقية في تطبيقات لينكس الخاصة بك، فكر في استخدام clock_gettime(). تقدم هذه الدالة عدة مزايا على gettimeofday():

فوائد clock_gettime()

1. توقيت أكثر دقة:

   • يمكنك استخدام CLOCK_MONOTONIC للحصول على وقت غير معرض للتغيرات الناتجة عن تحديثات الساعة النظامية، مما يجعلها مثالية لقياس الفواصل الزمنية.

2. تقليل القضايا مع الأنظمة متعددة النوى:

   • تدير التوقيت بشكل أفضل في بيئات المعالجات المتعددة وتقلل من الاضطرابات الناجمة عن إعدادات الساعة الخارجية.

الخطوات التالية: تنفيذ clock_gettime()

لتستبدل gettimeofday()، يمكنك إعادة كتابة وظيفة التوقيت الخاصة بك على النحو التالي:

#include <time.h>

BOOL QueryPerformanceCounter(LARGE_INTEGER* performanceCount)
{
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    performanceCount->QuadPart = ts.tv_sec * 1000000 + ts.tv_nsec / 1000; // تحويل إلى ميكروثواني

    return true;
}

مورد إضافي

لمزيد من المعلومات التفصيلية، يمكنك الاطلاع على صفحة الرجل لـ clock_gettime()—إنها تتفصل في الساعات المختلفة المتاحة واستخداماتها: صفحة رجل clock_gettime().

الخاتمة

عند تطوير تطبيقات أو ألعاب متوافقة عبر الأنظمة، يعد معرفة قيود وظائف التوقيت أمرًا بالغ الأهمية. بينما قد تكون gettimeofday() خيارًا شائعًا للحصول على الوقت الحالي، إلا أن موثوقيتها قد تنخفض في ظل ظروف معينة. من خلال اعتماد clock_gettime()، يمكنك التخفيف من العديد من هذه القضايا وضمان سلوك توقيت أكثر اتساقًا، وهو أمر أساسي للتطبيقات الحساسة للأداء.

الآن بعد أن فهمت تفاصيل استخدام gettimeofday() وفوائد التحول إلى clock_gettime()، يمكنك اتخاذ قرار مستنير لمشروع نقل لينكس الخاص بك.