Gerçek Zamanlı İşletim Sistemi (RTOS), verileri ve önemli zaman kısıtlamalı olayları işleyen gerçek zamanlı uygulamalar için işletim sistemi'dir.

RTOS, çoklu görev veya çoklu programlama ortamında sistem kaynaklarının zamanlayıcı, veri arabellekler veya sabit görev önceliği ile paylaşımını yöneten Unix gibi bir zaman paylaşımlı işletim sisteminden farklıdır. İşleme süresi gereksiniminin enaz tutulması yerine tam olarak anlaşılması ve sınırlandırılması gerekir. Tüm işlemler tanımlanan kısıtlamalar dahilinde gerçekleşmelidir. Gerçek zamanlı işletim sistemleri olay güdümlü ve önleyici'dir yani işletim sistemi rekabet eden görevlerin ilgili önceliğini izleyebilir ve görev önceliğinde değişiklik yapabilir. Olaya dayalı sistemler önceliklerine göre görevler arasında geçiş yaparken, zaman paylaşımlı sistemler saat kesintilerine göre görevler arasında geçiş yapar.

Özellikler

değiştir

RTOS'un önemli bir özelliği uygulamanın görevi kabul etme ve bitirmesi için gereken süreye ilişkin tutarlılık seviyesidir; değişkenlik bir çeşit 'titreşim'dir. (ing: jitter)[1]

"Sert" gerçek zamanlı işletim sisteminin (sert RTOS), "yumuşak" gerçek zamanlı işletim sisteminden (yumuşak RTOS) daha az titreşimi vardır. Geç cevap sert RTOS'ta yanlış cevap iken, yumuşak RTOS'da geç cevap olarak kabul edilebilir. Başlıca tasarım hedefi yüksek miktarda çıktı değil, yumuşak veya sert performans kategorisinin garantisidir. Genellikle veya genel olarak bir son teslim tarihini karşılayabilen bir RTOS, yumuşak bir gerçek zamanlı işletim sistemidir, ancak bir son teslim tarihini deterministik olarak karşılayabilirse, bu sert gerçek zamanlı bir işletim sistemidir.[2]

RTOS'un zaman programlaması için gelişmiş algoritması vardır. Zamanlayıcı esnekliği, işlem önceliklerinin daha geniş bir bilgisayar sistemi düzenlemesine olanak tanır, ancak gerçek zamanlı bir işletim sistemi daha çok dar bir uygulama grubuna ayrılmıştır. Gerçek zamanlı bir işletim sistemindeki temel faktörler minimum kesme gecikmesi ve minimum iş parçacığı değiştirme gecikmesidir; gerçek zamanlı bir işletim sistemi belirli bir sürede gerçekleştirebileceği iş miktarından çok, ne kadar hızlı veya ne kadar tahmin edilebilir şekilde tepki verebileceğine göre daha değerlendirilir.[3]

Tüm işletim sistemi türleri için işletim sistemleri listesi'ne bakın.

Tasarım felsefeleri

değiştir

RTOS, bir girdi uyaranını işlemek için geçen sürenin, aynı türden bir sonraki girdi uyaranına kadar geçen süreden daha kısa olduğu bir işletim sistemidir.

En yaygın tasarımlar şunlardır:

  • Olaya dayalı – yalnızca daha yüksek öncelikli bir olayın hizmete ihtiyacı olduğunda görevler arasında geçiş yapar; önleyici öncelik veya öncelik planlaması denilir.
  • Zaman paylaşımı – görevleri normal saatli bir kesintide ve olaylarda değiştirir; round-robin denilir.

Zaman paylaşımı tasarımları, görevleri kesinlikle gerekenden daha sık değiştirir ama daha sorunsuz çoklu görev sağlayarak, işlemin veya kullanıcının bir makineyi tek başına kullandığı yanılsamasını verir.

İlk CPU tasarımları, görevleri değiştirmek için CPU'nun yararlı başka hiçbir şey yapamadığı birçok döngüye ihtiyaç duyuyordu. Geçiş çok uzun sürdüğü için, ilk işletim sistemleri gereksiz görev geçişlerinden kaçınarak boşa harcanan CPU zamanını en aza indirmeye çalıştı.

Planlama

değiştir

Tipik tasarımlarda, bir görevin üç durumu vardır:

  1. Çalışıyor (CPU üzerinde yürütülüyor);
  2. Hazır (yürütülmeye hazır);
  3. Engellendi (örneğin I/O gibi bir olay bekleniyor).

CPU başına aynı anda yalnızca bir görev çalışabileceğinden çoğu görev çoğu zaman engellenir veya hazırdır. Hazır kuyruğundaki öğe sayısı, sistemin gerçekleştirmesi gereken görev sayısına ve sistemin kullandığı zamanlayıcı türüne bağlı olarak büyük ölçüde değişebilir. Daha basit, önleyici olmayan ancak yine de çok görevli sistemlerde, bir görevin CPU'daki zamanını diğer görevlere vermesi gerekir; bu da hazır kuyruğunun yürütülmeye hazır durumda daha fazla sayıda genel göreve sahip olmasına neden olabilir (kaynak açlığı).

Genellikle, programlayıcıdaki hazır listenin veri yapısı, önalımın engellendiği süre boyunca, programlayıcının kritik bölümünde harcanan en kötü durum süresini en aza indirecek şekilde tasarlanır ve bazı durumlarda tüm kesintiler devre dışı bırakılır ama veri yapısının seçimi aynı zamanda hazır listede olabilecek maksimum görev sayısına da bağlıdır.

Hazır listesinde hiçbir zaman birkaç görevden fazlası yoksa, hazır görevlerden oluşan çift bağlantılı liste muhtemelen en uygunudur. Hazır listesi genellikle yalnızca birkaç görev içeriyorsa, ancak bazen daha fazlasını içeriyorsa, liste önceliğe göre sıralanmalıdır. Bu şekilde, çalıştırılacak en yüksek öncelikli görevi bulmak, tüm listeyi yinelemeyi gerektirmez. Bir görev eklemek, listenin sonuna veya eklenen görevden daha düşük önceliğe sahip bir göreve ulaşana kadar hazır listede yürümeyi gerektirir.

Bu arama sırasında önalımı engellememeye özen gösterilmelidir. Daha uzun kritik bölümler küçük parçalara bölünmelidir. Düşük öncelikli bir görevin eklenmesi sırasında yüksek öncelikli bir görevi hazır hale getiren bir kesinti meydana gelirse, bu yüksek öncelikli görev eklenebilir ve düşük öncelikli görev eklenmeden hemen önce çalıştırılabilir.

Bazen geri dönüş süresi olarak adlandırılan kritik yanıt süresi, yeni bir hazır görevi kuyruğa almak ve en yüksek öncelikli görevin durumunu çalışır duruma getirmek için geçen süredir. İyi tasarlanmış bir RTOS'ta, yeni bir görevin hazırlanması her hazır kuyruk girişi için 3 ila 20 talimat alacaktır ve en yüksek önceliğe sahip hazır görevin geri yüklenmesi 5 ila 30 talimat alacaktır.

Daha gelişmiş sistemlerde gerçek zamanlı görevler, bilgi işlem kaynaklarını gerçek zamanlı olmayan birçok görevle paylaşır ve hazır liste keyfi olarak uzun olabilir. Bu tür sistemlerde, bağlantılı bir liste olarak uygulanan bir planlayıcı hazır listesi yetersiz kalacaktır.

Kaynakça

değiştir
  1. ^ "Response Time and Jitter". 23 Temmuz 2011 tarihinde kaynağından arşivlendi. 
  2. ^ Tanenbaum, Andrew (2008). Modern Operating Systems. Upper Saddle River, NJ: Pearson/Prentice Hall. s. 160. ISBN 978-0-13-600663-3. 
  3. ^ "RTOS Concepts". 23 Temmuz 2011 tarihinde kaynağından arşivlendi.