مهلتِ اجرایِ کار را با اختلافِ زمان در یک ساعتِ مناسب بسنجید، نه با کم‌کردنِ دو تاریخِ قابل‌تغییر. ساعتِ تقویمی برای ثبتِ زمانِ رویداد مفید است؛ ساعتِ monotonic برای فاصلهٔ زمان طراحی شده و از تغییرِ ساعتِ سیستم عقب نمی‌رود. این تمرین یک بودجهٔ۱۰ثانیه‌ای و دو مسیرِ ساعتِ تزریق‌شده دارد؛ ساعتِ دستگاه را تغییر نمی‌دهد و کارِ واقعی را متوقف نمی‌کند.
ده ثانیه از کدام مبدأ؟
در مدلِ کوچک، زمانِ آغازِ monotonic برابر۵۰ و deadline برابر۶۰ است. زمانِ باقی‌مانده را max(0,deadline-now) می‌گیریم. چهار مشاهدهٔ۵۰،۵۳،۵۷ و۶۲ به‌ترتیب۱۰،۷،۳ و۰ثانیه باقی می‌گذارند. پس از عبور از مرز، عددِ منفی برای ادامهٔ انتظار برنمی‌گردانیم.
مبدأِ این ساعت معنایِ تاریخِ عمومی ندارد. عددِ ۵۰ را timestampِ UTC یا ساعتِ شروعِ روز نمی‌نامیم. مقدارِ ذخیره‌شدهٔ یک ساعت را بدونِ قراردادِ یکسان با ساعتِ دیگر مقایسه نکنید؛ داشتنِ واحدِ «ثانیه» به‌تنهایی مبدأها را یکی نمی‌کند. این مثال بازیابیِ deadline در اجرایِ دوباره یا دستگاهِ دیگر را طراحی نکرده است.
اگر ساعتِ تقویمی عقب برود چه می‌شود؟
برای مقایسه، ساعتِ دیواریِ ساختگی از۱۰۰۰ شروع می‌شود و deadlineِ آن۱۰۱۰ است. مقدارها را۱۰۰۰،۱۰۰۳،۹۰۰ و۱۲۰۰ انتخاب کرده‌ایم. در مشاهدهٔ سوم، عقب‌رفتنِ ساعت باعث می‌شود محاسبهٔ ساده۱۱۰ثانیه باقی نشان بدهد؛ در حالی که ساعتِ monotonicِ همان مرحله فقط۳ثانیه از بودجه باقی دارد.
| مرحله | ساعتِ تقویمیِ تزریق‌شده | باقی‌ماندهٔ تقویمی | باقی‌ماندهٔ monotonic |
|---|---|---|---|
| آغاز | ۱۰۰۰ | ۱۰ | ۱۰ |
| دوم | ۱۰۰۳ | ۷ | ۷ |
| عقب‌رفتنِ ساعت | ۹۰۰ | ۱۱۰ | ۳ |
| عبور از مرز | ۱۲۰۰ | ۰ | ۰ |
عددها شاهدِ رخدادِ واقعیِ تنظیمِ ساعت نیستند. دو آرایهٔ ثابت به تابع داده‌ایم تا علتِ اختلاف روشن باشد. هیچ فرمانِ تغییرِ زمان، sleep، اتصالِ شبکه یا درخواستِ API اجرا نشده است.
مشخصاتِ ساعتِ موجود را جدا بخوانیم
کد علاوه بر مدلِ تزریق‌شده، get_clock_info را برای time،monotonic وperf_counterِ همین محیط می‌خواند. در اجرایِ ثبت‌شدهٔ Python۳٫۱۲٫۱۴ روی Windows، monotonic وperf_counter هر دو monotonic=True وadjustable=False دارند. implementation وresolution نیز در JSON آمده‌اند؛ آن‌ها را ویژگیِ همهٔ دستگاه‌ها معرفی نمی‌کنیم.
resolutionِ گزارش‌شده با خطایِ زمان‌سنجیِ کامل یا تأخیرِ پردازش یکی نیست. کد این صفحه benchmarkِ مدل ندارد. monotonic_ns وperf_counter_ns نمایشِ عددِ صحیحِ نانوثانیه می‌دهند، اما نامِ واحد به‌تنهایی ثابت نمی‌کند ساعت، دقتِ واقعیِ یک نانوثانیه دارد.
بودجهٔ کل را با timeoutِ هر تلاش اشتباه نگیریم
اگر یک کار چند مرحله دارد، دادنِ ۱۰ثانیهٔ تازه به هر مرحله می‌تواند از بودجهٔ کل عبور کند. در طراحیِ مبتنی بر deadline، باقی‌مانده از مرزِ مشترک گرفته می‌شود. برنامهٔ تمرین فقط چهار مقدار را حساب می‌کند؛ تقسیمِ بودجه بین اتصال، صف و پردازش را باید بر اساسِ قراردادِ همان اجرا تعیین کرد.
راهنمای timeout و تلاشِ مجدد وضعیتِ نامعلومِ عملیات و جلوگیری از اثرِ دوباره را پوشش می‌دهد. صحیح‌بودنِ ساعت، وضعیتِ مقصد را مشخص نمی‌کند. سقفِ تلاش و مصرف هم شمارنده‌ها و مرزِ اختیار را لازم دارد؛ رسیدنِ محاسبه به صفر، مجوزِ افزایشِ خودکارِ بودجه نیست.
انقضایِ مهلت، کارگر را خودکار لغو نمی‌کند
تابعِ remaining فقط عدد برمی‌گرداند. کارگر، ابزار یا سرویسِ بیرونی باید مسیرِ توقفِ خودش را داشته باشد. بنابراین JSON صریحاً worker_cancelled=False دارد. برای این مرز، لغوِ پردازشِ پس‌زمینه را جدا بخوانید؛ نمایشِ صفر یا بسته‌شدنِ مرورگر، شاهدِ توقف نیست.
برای ادامه در مبانی هوش مصنوعی، واحد، مبدأ، نوعِ ساعت و دامنهٔ اعتبارِ deadline را کنارِ گزارش بنویسید. اگر زمانِ پاسخ‌گوییِ پروژه مهم است، نیاز را در راهکارهای اپرا مشخص کنید؛ این تمرین نه تعهدِ سرعت می‌دهد و نه روشِ زمان‌سنجیِ محصول را اعلام می‌کند.
فایل تمرین و منبع
کد مستقلِ تمرینِ محدود · تمام خروجیِ واقعیِ همین تمرین؛ JSON
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.