Interrupt Context — CPU hardware interrupt yoki ayrim soft interrupt handlerini joriy thread oqimidan tashqari, kechiktirib bo‘lmaydigan kernel holatida bajarayotgan kontekst.
Handler oqimi
Interrupt kelganda CPU minimal state’ni saqlab handlerga o‘tadi. Handler qurilma holatini tasdiqlaydi, eventni qayd etadi va imkon qadar tez qaytadi. Uzoq ish deferred mechanismga beriladi.
Bloklanish cheklovi
Interrupt context sleep qilmaydi, blocking mutex kutmaydi va page faultga tayanmaydi. Sababi uni rejalashtirish uchun mustaqil process context yo‘q yoki resurs egasi ayni CPUda to‘xtatilgan bo‘lishi mumkin.
Deferred ish
Top half tez hardware ishini, bottom half yoki threaded interrupt esa kechiktiriladigan ishlovni bajaradi. Threaded handler scheduler boshqaradigan contextda bo‘lib, ko‘proq blocking imkoniga ega.
Shared data
Shared data interrupt va process contextdan ko‘rilsa spinlock, atomic yoki interrupt disable protokoli kerak. Faqat bir CPUda interruptni o‘chirish boshqa CPU accessini to‘xtatmaydi.
Nested interrupt
Nested interrupt priority va stack sarfini oshiradi. Interrupt storm rate limiting, masking va pollingga o‘tish orqali boshqarilishi mumkin. Handler loglashda ham bounded va nonblocking yo‘l ishlatadi.
Latency testi
Test yuqori interrupt chastotasi, nested handler, CPU migration va device removalni qamraydi. “Sleeping in atomic context” assertion hamda latency tracing ishlatiladi.
Amaliy boshqaruv
Interrupt Context implementatsiyasida handler state va deferred work alohida va versiyalangan holat sifatida yuritiladi. Qaror uchun zarur inputlar yashirin global taxminga aylantirilmaydi: platforma, konfiguratsiya, identity yoki memory-order sharti tegishli obyekt bilan bog‘lanadi. Shu sabab incremental yangilanish, context almashishi yoki parallel hodisada eskirgan ma’lumotdan foydalanish kamayadi. Debug rejim qarorni hosil qilgan edge, state transition va parametrlarni ko‘rsatadi; production log esa maxfiy qiymatlarni xom shaklda yozmaydi.
Muhim xato sinfi — blocking, storm yoki nested-stack overflow. Bunday vaziyatda tizim optimistik tarzda davom etmaydi: semantikaga qarab konservativ fallback, bounded retry, taskni bloklash yoki aniq error tanlanadi. Timeout correctness isboti emas; u faqat operatsion limitdir. Queue membership, reference count, lock ownership va visibility kabi invariantlar state bilan atomik yangilanadi. Cancellation yoki failure o‘rtada yuz bersa qisman o‘zgargan holat cleanup protokoli orqali tiklanadi.
Sifat nazorati latency trace va high-rate interrupt orqali bajariladi. Test normal yo‘ldan tashqari bo‘sh navbat, bitta element, yuqori contention, timeout bilan bir vaqtdagi wakeup, resurs limiti va platforma variantlarini qamraydi. To‘g‘rilik performance’dan alohida tekshiriladi; keyin throughput, p99 latency, context switch, cache miss yoki artefakt hajmi kabi mavzuga mos ko‘rsatkichlar baseline bilan solishtiriladi. Topilgan minimal interleaving yoki kirish regressiya to‘plamida doimiy saqlanadi.
Interrupt handler device statusni acknowledge qilmasa bir interrupt qayta-qayta kelib storm yaratishi mumkin. Acknowledge tartibi device memory barrier bilan bog‘liq. Shared IRQ’da handler o‘z qurilmasi sababchi bo‘lmagan eventni ajratadi va boshqa handlerlar ishlashiga xalaqit bermaydi.
Per-CPU interrupt statistikasi handler runtime, maksimal kechikish va dropped eventni ko‘rsatadi. Threshold oshsa device queue va deferred worker holati birga tekshiriladi.
Bog‘liq tushunchalar
interrupt handler, top half, bottom half, atomic context, spinlock, interrupt latency