işletim sistemleri

ĠġLETĠM SĠSTEMLERĠ
DERS NOTLARI
HAZIRLAYANLAR :
PROF. DR. MESUT RAZBONYALI
YRD. DOÇ.DR. ERDEM UÇAR
TRAKYA ÜNĠVERSĠTESĠ BĠLGĠSAYAR MÜHENDĠSLĠĞĠ BÖLÜMÜ
EDĠRNE - 1995
ĠÇĠNDEKĠLER
BÖLÜM I : GENEL TANIM VE KAVRAMLAR
1.1. ĠĢletim Sisteminin Önemi .................................................................. [7]
1.2. ĠĢletim Sisteminin GeliĢimi ................................................................ [8]
1.3. ĠĢletim Sistemi ve Kapsamı ................................................................ [11]
1.4. Kaynak BölüĢümü ............................................................................. [12]
1.5. Job (ĠĢ) .............................................................................................. [14]
1.6 Task (Görev) ...................................................................................... [16]
2. ĠĢletim Sistemi Türleri .......................................................................... [17]
2.1. ÇalıĢma Ortamına Göre Sınıflama ........................................... [17]
2.1.1. Tek ĠĢ Düzeni (Monoprogramming) ......................... [18]
2.1.2. Çok ĠĢ Düzeni (Multiprogramming) .......................... [18]
2.1.3. Çok Görevli ĠĢlem (Multitasking) ............................. [20]
2.2. Sistem Kullanım Biçimine Göre Sınıflama .............................. [21]
2.2.1. AdanmıĢ ĠĢlem (Dedicated Processing) ..................... [21]
2.2.2. Toplu ĠĢlem (Batch Processing) ................................ [22]
2.2.3. EtkileĢimli ĠĢlem (Interactive Processing) .................. [23]
2.3. Yapılara Göre Sınıflama ......................................................... [24]
3. ĠĢletim Sistemlerinde Temel ĠĢlevler ...................................................... [24]
3.1. Yazılım-Donanım Bütünlüğünün Sağlanması .......................... [25]
3.2. Kaynakların Yönetimi ............................................................ [25]
3.2.1. Ana Belleğin Yönetimi ............................................. [27]
3.2.2. Ana ĠĢlem Biriminin Yönetimi .................................. [28]
3.2.3. Yan Ünitelerin Yönetimi .......................................... [30]
3.2.4. Verilerin Yönetimi ................................................... [31]
3.3. Kullanıcıların Yönetimi .......................................................... [32]
BÖLÜM II : ÇEKĠRDEK SĠSTEM
4. GiriĢ ....................................................................................................
4.1. Kesilmelerin Yönetimi ...........................................................
4.2. Kesilme Türleri ......................................................................
4.3. Kesilmelerde Sıradüzen ..........................................................
4.4. Kesilmelerin ĠĢlenmesi ...........................................................
5. GiriĢ / ÇıkıĢ Donanımının Yönetimi ......................................................
5.1. Bağlantı Arabirimi .................................................................
5.2. G/Ç Hattı ...............................................................................
5.3. Kanallar .................................................................................
5.3.1. Kanalların ÇalıĢma Ġlkeleri .......................................
5.3.2. Kanal Türleri ...........................................................
5.4. GiriĢ/ÇıkıĢların Programlanması .............................................
5.4.1. Durum Belirteçlerinin Kullanılması ..........................
5.4.2. Kesilme Sisteminin Kullanılması ..............................
2
[34]
[34]
[34]
[35]
[36]
[37]
[38]
[40]
[42]
[42]
[43]
[45]
[46]
[46]
6. Donanımda Öngörülmeyen Komutların ĠĢletimi ..................................... [47]
BÖLÜM III : VERĠLERĠN YÖNETĠMĠ
7. Veri Yönetim Sisteminin BileĢenleri ......................................................
7.1. GiriĢ/ÇıkıĢ Yönetim Sistemi ...................................................
7.2. Kütük Yönetim Sistemi ..........................................................
8. Kütük Yönetim Sisteminin ĠĢlevsel Kesimleri ........................................
8.1. Mantıksal Düzey ....................................................................
8.1.1. Tek Düzeyli Kılavuz Yapısı .....................................
8.1.2. Çok Düzeyli Kılavuz Yapısı .....................................
8.2. Temel Düzey .........................................................................
8.3. Fiziksel Düzenleme Kesimi ....................................................
8.4. Stratejik Yönetim Kesimi .......................................................
9. Genel Amaçlı Bir Kütük Yönetim Sistemi .............................................
9.1. Mantıksal Düzey ....................................................................
9.2. Temel Düzey .........................................................................
[48]
[49]
[50]
[50]
[52]
[52]
[54]
[55]
[56]
[56]
[58]
[58]
[60]
BÖLÜM IV : ANA BELLEK YÖNETĠM SĠSTEMĠ
10.1. Ana Bellek Yönetimi ĠĢlevleri .......................................................... [62]
10.1.1. Adlandırma ĠĢlevi .............................................................. [62]
10.1.2. Bellek ĠĢlevi ...................................................................... [64]
10.2. Ana Belleğin Düzenlenmesi ............................................................. [64]
10.2.1. Gerçek Ana Bellek Yönetimi .......….................................. [65]
10.2.1.1. Single Contiguous (Tek ve Kesintisiz)
Bellek Yönetimi .................................................. [65]
10.2.1.2. Partitioned (Bölümlere Ayırarak)
Bellek Yönetimi .................................................. [67]
10.2.1.3. Relocatable Partitioned (Yer DeğiĢir Bölümlü)
Bellek Yönetimi .......................................…… [83]
10.2.1.4. Paged (Sayfalı) Bellek Yönetimi .......................... [89]
10.2.2. Görüntü Ana Bellek Yönetimi ............................................ [100]
10.2.2.1. Demand-Paged (Ġstenebilir-Sayfalı) Bellek
Yönetimi .............................................................. [100]
10.2.2.2. Segmented (Kesimleme) Bellek Yönetimi ............ [112]
10.2.2.3. Segmented And Demand-Paged (Kesimleme
ve Ġstenebilir-Sayfalı) Bellek Yönetimi ................ [115]
10.2.3. Diğer Bellek Yönetim Teknikleri ....................................... [118]
BÖLÜM V : CPU YÖNETĠMĠ (PROCESSOR MANAGEMENT)
11.1. Temel Kavramlar .............................................................................
11.2. Schedular ........................................................................................
11.3. Traffic Controller ............................................................................
11.4. Process Senkronizasyonu .................................................................
11.4.1. Race Condition (YarıĢ Durumu) ........................................
3
[119]
[120]
[121]
[122]
[122]
11.4.2. Deadly Embrace (Öldürücü KucaklaĢma) .......................... [123]
11.5. Multiprocessor Sistemler ................................................................. [124]
BÖLÜM VI : KULLANICILARIN YÖNETĠMĠ
12.1. GiriĢ ................................................................................................
12.2. ĠĢ Yönetimi-Görev Yönetimi ĠliĢkisi .................................................
12.3. ĠĢ Yönetimi-Görev Yönetimi EtkileĢimi ............................................
12.4. Görev Yönetimi ...............................................................................
12.5. ĠĢ Yönetimi .....................................................................................
[128]
[128]
[129]
[131]
[132]
BÖLÜM VII : BĠRLĠKTE ÇALIġAN GÖREVLER (CONCURRENT TASKS)
13.1. Process (Süreç) Kavramı .................................................................. [134]
13.2. Kesilme ĠĢleme ................................................................................ [136]
13.2.1. Kesilme Türleri ................................................................. [136]
13.2.2. Context Switching (Bağlam / Kullanma Yeri
DeğiĢtirme) ....................................................................... [137]
13.2.3. Kernel (Çekirdek) ............................................................. [137]
14. Birlikte ÇalıĢan Görevler (Concurrent Tasks) ....................................... [138]
14.1. Görevler Arası EtkileĢim ...................................................... [138]
14.2. Görevler Arası Zamanuyumu ................................................ [138]
14.3. Birlikte ÇalıĢan Görevlerde Zaman Ġçinde OluĢan
Hatalar ................................................................................
[138]
14.4. Altdüzeyli Zamanuyumu ĠĢlevleri ......................................... [140]
14.4.1. Ana Bellek EriĢimli Kilitlenme ............................... [140]
14.4.2. Bölünmez Komutlar ............................................... [142]
14.4.3. Semaforlar ............................................................. [143]
14.4.3.1. Senkronizasyon Semaforları ..................... [146]
14.4.3.2. KarĢılıklı DıĢlama Semaforları ................. [146]
15. Görevler Arası ĠletiĢim ........................................................................ [147]
16. Üst Düzeyli Zamanuyum ĠĢlevleri ....................................................... [151]
16.1. Tek Yönlü Posta Kutusu ...................................................... [151]
16.2. Çift Yönlü Posta Kutusu ....................................................... [151]
16.3. Çift GiriĢli Posta Kutusu ....................................................... [151]
16.4. Kapılar ................................................................................
[151]
16.5. Hoare Monitor'u ................................................................... [152]
16.6. Monitor Görevler ................................................................. [153]
17. Örnekler ............................................................................................. [153]
17.1. Okuyucu ve Yazıcılar ........................................................... [153]
18. Kilitlenme (Deadlock) ........................................................................ [153]
18.1. Sürekli Kaynaklarda Kilitlenme ............................................ [154]
18.2. ĠĢletim Sistemlerinde Kilitlenmelerin Çözümlenmesi ............. [155]
18.3. Kilitlenmeleri Engelleme ...................................................... [155]
18.3.1. Banker Algoritması ................................................ [155]
18.3.2. Sıradüzensel Kaynak Atama ................................... [157]
4
18.3.3. Görevlerde Sıradüzensel ĠletiĢim ............................. [158]
BÖLÜM VIII : VM ĠġLETĠM SĠSTEMĠ
19. GiriĢ ...................................................................................................
[161]
19.1 Tarihçe ................................................................................. [166]
20. Kontrol Programı (Control Program) ................................................... [168]
21. Demand Paging (Ġstenebilir Sayfalama) .................................... [169]
22. Minidiskler ......................................................................................... [170]
23. Konsol Yönetimi ................................................................................ [171]
24. CP Kullanıcı Öncelik Sınıfları ............................................................. [172]
25. VM Directory'si .................................................................................. [173]
26. CMS-Conversational Monitor System ................................................. [174]
27. RSCS (Remote Spooling Communications System).............................. [177]
28. VM'in gücü ........................................................................................
[178]
29. VM/370'in GeliĢimi ............................................................................ [178]
30. Performansı Etkileyen Faktörler .......................................................... [178]
31. Görüntü Makine Yardım Özelliği ........................................................ [179]
32. Uzantılı Kontrol Program Destek Özelliği ........................................... [179]
33. Performans Ölçme ve Analiz ............................................................... [179]
34. VM:IBM'in 1980'li Yıllar Ġçin Büyük Ölçek ĠĢletim Sistemleri ............. [180]
35. Özet ...................................................................................................
[182]
BÖLÜM IX : UNIX ĠġLETĠM SĠSTEMĠ
36. Unix ĠĢletim Sistemi .......................................................................... [184]
36.1. Tarihçe ............................................................................... [184]
36.2. Tasarım Ġlkeleri ................................................................... [186]
36.3. Programcı Arayüzü ............................................................ [187]
36.3.1. File ĠĢleme ................................................. [188]
36.3.2. ĠĢlem Kontrol ............................................. [191]
36.3.3. Sinyaller ..................................................... [192]
36.3.4. Bilgi ĠĢleme ................................................ [193]
36.3.5. Kütüphane Rutinleri .................................... [193]
36.4. Kullanıcı Arayüzü . ............................................................. [193]
36.4.1. Shell ve Komutlar ....................................... [194]
36.4.2. Standart G/Ç ............................................... [195]
36.4.3. Pipeline'lar, Filtreler ve Shell Yazıları .......... [195]
36.5. File Sistemi...........................................................................[196]
36.5.1. Bloklar ve Parçalar .................................... [196]
36.5.2. Inodes (index noktası) .................................[197]
36.5.3. Direktoriler ................................................ [198]
36.5.4. File Tanımlayıcısının Inode'a bağlanması..... [199]
36.5.5. Disk Yapıları ............................................. [199]
36.5.6. Yürütmeler ................................................ [201]
36.5.7. Layout ve Atama Politikaları ...................... [201]
36.6. ĠĢlem Yöneticisi ……........................................................... [204]
5
36.6.1. ĠĢlem Kontrol Blokları................................ [204]
36.6.2. CPU Scheduling ........................................ [207]
36.7. Bellek Yönetimi ........................................................…….…[208]
36.7.1. DeğiĢtirme(swapping) ................................. [208]
36.7.2. Sayfalama(paging) .................................…. [209]
36.8. GiriĢ-ÇıkıĢ Sistemleri ………................................................ [211]
36.8.1. Blok Buffer Cache ...................................... [213]
36.8.2. Raw Aygıtların Arayüzleri .......................... [214]
36.8.3. C Listeleri .. ............................................... [214]
36.9. ĠĢlemler Arası ĠletiĢim …......………..................................... [214]
36.9.1. Soketler ...................................................... [215]
36.9.2. Network (ağ) Desteği ..................................[217]
6
BÖLÜM 1
GENEL TANIMLAR VE KAVRAMLAR
1.1. ĠĢletim Sisteminin Önemi
ĠĢletim sistemi, bilgisayar donanımı ile bilgisayar kullanıcısı arasında arayüz
görevi yapan programlar topluluğudur. ĠĢletim sisteminin amacı ise, bilgisayar
kullanıcılarına programlarını çalıĢtırabilecekleri bir ortam hazırlamak ve bilgisayar
donanımının etkin kullanımını sağlamaktır.
Bir bilgisayar sisteminin genel olarak dört bileĢeni vardır. Bunlar;
1) Donanım (CPU, Bellek, G/Ç Aygıtları),
2) Ġletim sistemi,
3) Uygulama programları (Compilers, Assembler, Loaders, Database Systems,
vb.),
4) Kullanıcılar (Ġnsanlar, diğer bilgisayarlar),
dır. ĠĢletim sisteminin bu bileĢenler açısından donanım ile iliĢkisi ġekil-1a'da, temel
bilgisayar donanımı ise ġekil-1b'de gösterilmiĢtir.
Ġnsan
Uygulama
Programları
Hata
Tarama
Hazır
Programlar
Makro
ĠĢleyici
Compilers
Assembler
Text
Editör
Loaders
ĠġLETĠM SĠSTEMĠ
Bellek
Yönetimi
CPU
Yönetimi
Yan-Üniteler
Yönetimi
Bilgi
Yönetimi
B Ġ L G Ġ S A Y A R
ġekil-1a. ĠĢletim Sisteminin Bilgisayar Donanımı ile ĠliĢkisi
7
Ana Bellek
İkincil
Bellek
Bellek
Bellek
G/Ç
İşleyici
(Kanal)
G/Ç
İşleyici
(Kanal)
Kontrol
Ünitesi
Kontrol
Ünitesi
Merkezi
...... İşleyici
(CPU)
Yazıcı
Disk
Teyp
Merkezi
İşleyici
(CPU)
Terminal
Drum
ġekil-1b. Temel Bilgisayar Donanımı.
Temel bilgisayar kaynakları donanım tarafından sağlanmaktadır. Bu kaynakların
kullanımı, kullanıcı sorunlarının çözümü için yazılmıĢ olan uygulama programlarıyla
gerçekleĢtirilmektedir. ĠĢletim sistemi, uygulama programlarıyla donanım arasındaki
iletiĢimi sağlamaktadır.
ĠĢletim sistemi bir "kontrol program"dır. Kontrol programının amacı, kullanıcı
programlarının çalıĢmasını sağlamak, bilgisayarın uygunsuz kullanımına ve hatalara yol
açmasına engel olmaktır.
1.2. ĠĢletim Sisteminin GeliĢimi
1940 senelerinin ortalarında günümüze kadar olan süre içinde bilgisayar
sistemlerinin geliĢmesini ve buna paralel olarak bu sistemlerin kullanım yönünden
geçirmiĢ oldukları değiĢiklikleri gözden geçirecek olursak karĢımıza Tablo 1'deki
görünüm çıkmaktadır.
8
1946 - 1952 Instruction-by-instruction processing
1952 - 1957 Job-by-job processing
1957 - 1962 Batch processing
1962 - 1967 Multi-programming
1967 Time-sharing
Tablo-1 ĠĢletim Sistemlerinin GeliĢimi.
Instruction-by-instruction processing olarak tanımlanan süre içinde, bilgisayarın
çalıĢmaları elle kontrol edilmekteydi. ġöyle ki; günümüzde "operatör" olarak bilinen
kiĢi, o zamanlar bu kiĢi iyi bir programcı ve hatta bir bilgisayar mühendisi olmak
zorundaydı, elindeki iĢin niteliğine göre teypleri takar, kart okuyucusunu yükler v.b. ve
sonra konsol üzerindeki tuĢları ve anahtarları (switches) kullanarak programı baĢlatırdı.
ĠĢ bitiminde operatör teypleri çıkarır, kartları okuyucudan alır, yazıcıyı ayarlar ve sonra
ikinci bir iĢi için gereken hazırlıkları yapardı. Bilgisayar teknolojisinin o günlerde böyle
bir çalıĢma Ģekli bir dereceye kadar geçerliydi, çünkü SET-UP-TIME denilen operatörün
bir iĢ için gereken hazırlıkları yapma süresi ile RUN-TIME denilen o iĢin kullanıldığı
bilgisayar zamanı arasındaki fark genellikle göz yumulabilecek bir dereceydi. Ancak
daha sonraki yıllarda bilgisayarların iĢlem yapma hızları giderek artmıĢ ve dolayısıyla
SET-UP-TIME RUN-TIME oranı da aynı ölçüde büyümeye baĢlamıĢtır. Böylelikle
bilgisayar sistemlerinin daha verimli bir Ģekilde kullanılabilmesi için "bir iĢten diğer bir
iĢe" geçiĢ iĢlemlerinin otomatikleĢtirilmesi yolları aranmaya baĢlanmıĢtır.
Bilgisayarların daha doğrusu merkezi iĢlem ünitelerinin (CPU) hızlanması, diğer
yandan tamamen elektro-mekanik prensiplere dayalı olarak çalıĢan yazıcı, teyp ve kart
okuyucu gibi giriĢ-çıkıĢ ünitelerinin hızlarıyla CPU hızı arasındaki farkın da gittikçe
açılmasına neden olmuĢtur. Bu hız farkının veya uyumsuzluğunun giderilmesi için
yapılan çalıĢmalar sistemcilik yönünden iki ayrı ve önemli geliĢmeyle sonuçlanmıĢtır.
Bunlardan biri G/Ç kanallarının, diğeri ise OFF-LINING-I/O (G/Ç) adı verilen bir giriĢçıkıĢ tekniğinin geliĢtirilmesi olmuĢtur.
Temel olarak g/ç kanalı adı verilen birim, sisteme bağlı giriĢ-çıkıĢ ünitelerinin
CPU' dan mümkün olduğu kadar bağımsız bir Ģekilde çalıĢmalarını sağlayan bir aygıttır.
g/ç yapılacağı zaman CPU'dan kaynaklanan bir komutla kanal uyarılmakta ve o g/ç
iĢlemi için gereken iĢlemler kanal tarafından otomatik olarak yapılmaya baĢlanmaktadır.
Bu sırada CPU diğer bir iĢ üzerinde çalıĢmakta ve aynı zamanda kanala verilen görevin
bitip bitmediğini belirli zamanlarda kontrol etmektedir. Bu Ģekilde g/ç kanallarının
kullanılmasıyla CPU gücünün, kendisinden çok daha yavaĢ çalıĢan giriĢ/çıkıĢ üniteleri
üzerinde harcanması önlendiği gibi, giriĢ/çıkıĢ iĢlemleriyle processing iĢlemlerinin
paralel yürütülmesi gerçekleĢtirilmiĢtir.
Diğer yandan OFF-LINING-I/O adını verdiğimiz tekniğin geliĢtirilmesiyle, g/ç
kanallarında olduğu gibi, CPU'nun da kendinden çok daha yavaĢ çalıĢan giriĢ/çıkıĢ
üniteleri ile direkt iliĢki kurması önlenmiĢtir. Bu tekniğin temelini ise "bilgilerin
görüntüleĢtirilmesi" kavram oluĢturmaktadır. Örneğin; bir satır yazıcısı, bir kart
okuyucusu ve bir manyetik teyp ünitesinden oluĢan bir bilgisayar sistemi düĢünelim.
Böyle bir sistemde kartlardan okunması gereken bilgilerin, önce kart görüntüleri
Ģeklinde manyetik teybe kaydedilmesi ve gerektiğinde oradan okunması CPU'nun daha
9
etkin bir Ģekilde kullanılmasını sağlar. Çünkü bilgi aktarma hızı yönünden manyetik
teyp bir kart okuyucusundan en az yüz kat daha hızlıdır. Yine aynı sistemde ana bellekte
kayıtlı bilgilerin satır yazıcısına gönderilmesi gerektiğini düĢünelim. Aynı düĢünce ile
bu bilgilerin satır yazıcısı görüntüsünde önce manyetik teybe kaydedilmeleri ve daha
sonra buradan alınıp yazıcıya gönderilmeleri CPU'nun daha etkin bir Ģekilde
kullanılmasını sağlayacaktır.
1950'lerin ikinci yarısında kullanılmaya baĢlanan bilgisayar sistemlerinde g/ç
kanallarının ve OFF-LINING-I/O
tekniğinin kullanılması g/ç - processing
paralelizminin ve dolayısıyla CPU gücünün çok daha etkin bir Ģekilde kullanılmasını
sağlamıĢtır. Özellikle manyetik teyp ve disk kullanılarak OFF-LINING- I/O tekniğinin
uygulanması, daha önce sözü edilen JOB-SET-UP-TIME ile PROCCESSING TIME
arasındaki uyumsuzluğun giderilmesini sağlamıĢtır. Bu Ģekilde sisteme girilmesi istenen
iĢler teypler üzerine kaydedilmekte ve bir iĢlem diğerine geçiĢ otomatik olarak
MONITOR adı verilen bir program tarafından sağlanmaktaydı. Böyle bir çalıĢma Ģekli
bugün BATCH PROCESSING adını verdiğimiz çalıĢma yönteminin temelini
oluĢturmaktadır.
Batch Processing'den sonra en büyük geliĢme Multi-Programming sistemlerdir.
Bu geliĢmenin temelini interrupt (kesinti) kavramı oluĢturmuĢtur. G/Ç kanallarından söz
ederken CPU'nun kanala bir g/ç komutu verdiğini ve bu kanal iĢlemi yaparken CPU'nun
belirli aralıklarla bu iĢin bitip bitmediğini kontrol etmesi gerektiğini vurgulamıĢtık. ĠĢte
CPU'nun bu kontrolü yapması yerine kanalın CPU'ya verilen görevin bitiminde özel bir
sinyal ile haber vermesi inturrupt kavramını ortaya çıkarmıĢtır.
G/Ç görevi verilen kanal iĢlemini bitirdiğinde CPU'ya bir interrupt sinyali
gönderir. Bu sinyali alan CPU o anda çalıĢtırmakta olduğu programı durdurur ve
inturrupt yapan kanala iliĢkin programa girer, burada gereken kontrolü yaptıktan sonra
eğer baĢka bir g/ç iĢlemi varsa kanalı yeniden görevlendirir ve tekrar interrupt sinyali ile
kesintiye uğrayan programı ele alır. Interrupt kavramı her ne kadar basit bir kavram
olarak gözüküyorsa da giriĢ-çıkıĢ ünitelerinin veya daha doğrusu g/ç kanallarının sürekli
kontrol edilmesi yükünü CPU'nun üzerinden kaldırması ve dolayısıyla giriĢ-çıkıĢ
ünitelerinin, kanallarının çalıĢabilecekleri en büyük hızlarıyla iĢlem yapmalarını
sağlaması yönünden büyük bir önemi vardır.
Önceleri interrupt mekanizması yalnızca tek bir programa iliĢkin olarak
kullanılmaktaydı. Ancak sonraları 1960'ın ilk yarısında böyle bir mekanizma yardımı ile
birçok programın aynı anda aynı CPU'yu kullanarak çalıĢtırılabileceği saptanmıĢtır.
ġöyle ki, sistemde bulunan programlardan biri, bir g/ç iĢleminin sonuçlanmasnı
beklemek zorunda kalacak olursa, o g/ç iĢlemi yapılırken diğer bir program CPU
kontrolünü alabilir ve bu ikinci program bir g/ç iĢlemi yapma durumuna geldiğinde CPU
kontrolü tekrar birinci programa veya üçüncü bir programa verilebilir. ĠĢte bilgisayar
sistemlerinin bu Ģekilde kullanılmaları bugün Multi-Programming adını verdiğimiz
çalıĢma Ģeklini ortaya atmıĢtır. Multi-Programming, CPU'nun peripheral-limited (çok
g/ç) programlarla processor-limited (çok iĢlem) iĢler arasında etkin paylaĢımını sağlayan
bir çalıĢma yöntemidir.
10
Multi-Programming yönteminden baĢka bir Ģekilde de yararlanılabilir. CPU'nun
yalnız g/ç bekleyen (peripheral-limited) veya CPU'yu bekleyen (processor-limited)
programlar arasında paylaĢımlı kullanılması gerekmez. Nitelikleri ne olursa olsun birçok
program aynı CPU'yu belirli sürelerle (quantum) ele geçirip iĢlem yapabilirler. Bu
Ģekilde o anda sistemde bulunan bütün programların paralel olarak ilerledikleri izlenimi
verilebilir. Özellikle bu programların her biri sisteme yakın (local) veya sisteme uzak
(remote) terminallerle iliĢkili olursa, terminal kullanıcılarının her birine sanki o sistemi
yalnız onlar kullanıyormuĢ izlenimi verilebilir. ĠĢte bu çalıĢma Ģeklinin uygulandığı
sistemlere MULTI-ACCESS ve çalıĢma Ģekline de INTERACTIVE veya TIMESHARING adı verilmektedir.
Ancak burada vurgulanması gereken önemli bir nokta, time-sharing ile multiprogramming arasındaki farkın belirlenmesidir. Bu iki kavram arasında en belirgin fark
real-time-response, yani sistemden bir iĢin yapılması için istekte bulunulması ile o iĢin
yapıldığına iliĢkin yanıtın alınması arasında geçen zaman yönündendir. MultiProgramming yönteminin kullanıldığı sistemlerde CPU kontrolünü elinde bulunduran
program, CPU'yu ya iĢi bittiğinden, ya g/ç transferi beklemek zorunda kaldığından, ya
da kendinden daha öncelikli bir programın CPU'yu elde etmesiyle bırakır. Multi-access
sistemlerde ise CPU kontrolünün belirli sürelerde bir programdan diğerine geçirilmesi
söz konusudur. Böylece terminal kullanıcılara geçerli bir servis veya baĢka bir deyimle
geçerli bir "response-time" sağlanmıĢ olmaktadır.
1.3. ĠĢletim Sistemi ve Kapsamı
Bir bilgisayar sisteminden istenen hizmet, fiziksel ve mantıksal olarak
sınıfladığımız, donanım ve yazılım nitelikli kaynakların birlikte iĢletilmeleri sağlanır.
Örneğin, bir kullanıcının Fortran programlama dili ile geliĢtirdiği uygulama programını,
bir bilgisayar sisteminde çalıĢtırabilmesi için; programını ve verilerini okutacağı giriĢ
birimleri, sonuçların alınacağı çıkıĢ birimleri, iĢlemin yapılacağı ana bellek, ana iĢlem
birimi gibi donanımın yanı sıra, programı çalıĢmaya hazır duruma getirecek derleyici,
bağlayıcı, yükleyici gibi yazılım nitelikli kaynaklara gereksinimi vardır. Bu kaynakların
amaçlanan iĢe gereken sırada ve sayıda yöneltebilmesi için, kullanıcının beklediği
hizmeti, bu hizmetin koĢul ve niteliğini, bilgisayar sistemine aktarabilmesi gereklidir.
Bir bilgisayar sisteminde, kullanıcı ile iletiĢim kurarak, istenen hizmeti karĢılayacak
kaynakları iĢe yöneltecek, bu kaynakların birbiriyle uyumlu çalıĢmalarını sağlayacak
aracı, "ĠĢletim Sistemi" diye adlandırıyoruz.
Bilgisayar sistemi üreten hemen her kuruluĢ, pazarladığı donanım ile birlikte,
fiziksel kaynakların kolayca kullanılmasını sağlayan temel yazılımı da vermektedir.
Donanım üzerindeki güç denetim iĢlevlerini yürüten, fiziksel birimleri denetleyen,
kısaca donanımın çeĢitliliğini ve karmaĢıklığını kullanıcılara yansıtmamaya çalıĢan bu
çekirdek sistem "Supervisor", "Monitor" gibi adlarla anılmaktadır. Ġlk kuĢak
bilgisayarlarda bu yazılım katmanı, iĢletim sisteminin en büyük kesimini
oluĢturmaktaydı.
Bilgisayar sistemlerinden beklenen hizmetin çeĢitliliği ve düzeyi, bu aracın
kullanımına, uygulama alanlarının yayılmasına paralel olarak artmıĢtır. Yapımcılar,
11
değiĢik beklentileri karĢılayabilmek üzere, ilk aĢamada, çekirdek sistemin üzerine birçok
yazılım katmanı eklemiĢlerdir (ġekil-2). Pazarlama ürününün genel amaçlı olmasını,
baĢka bir deyiĢle yeni görevlere kolaylıkla yöneltilebilmesini sağlamak üzere iĢletim
sistemlerine katılan yazılımın hacmi, günümüzdeki sistemlerde bile, çekirdek
yazılımdan onkat daha fazladır.
Yazılım
Donanım
Kullanıcıların
Yönetimi
Uygulama
Kaynakların
Yönetimi
Programları
Ç
e
k
i
r
d
e
k
S
i
s
t
e
m
B
e
l
l
e
n
i
m
D
o
n
a
n
ı
m
Bilgisayar Sistemlerinin Gelişme Yönü
İşletim Sistemleri Kapsamında
İşlenecek Konular
ġekil-2. ĠĢletim Sistemlerinde Katmanlar
Bir iĢletim sisteminin, gerektiğinde yeni bir yazılım katmanı daha eklenerek
geliĢtirilmesi, çoğunlukla sağlıklı bir büyümeye yol açmamıĢtır. Yazılım yığınlarından
oluĢan hantal ve anlaĢılmaları giderek güçleĢen bu tür sistemlerin, kullanıcıların iĢ
yükünü her zaman hafiflettikleri söylenemez. Ayrıca, iĢletim sistemlerinin kullanıcılara;
sistemdeki aksamaları en az yansıtan, güvenilir ve iĢletim bütünlüğünü koruyan bir
ortam hazırlaması için yazılım yolu ile yapılacak iyileĢtirmeler de, artık doyum
noktasına ulaĢmaya baĢlamıĢtır. Özellikle seksenli yılların baĢında, bilgisayar
sistemlerinin yapıları geliĢtirilerek, geçmiĢte çekirdek sistemin ve daha üst düzeyli
katmanların üstlendiği birçok iĢlevin donanımca yapılmasına çalıĢılmaktadır.
1.4. Kaynak BölüĢümü
Bilgisayar sistemini oluĢturan fiziksel kaynaklar, çoğu uygulamada, tek bir
kullanıcı tarafından tümüyle tüketilemez. BoĢta kalan kaynaklar, sistemin verimli
kullanım düzeyini düĢürdüklerinden, bunların eĢzamanlı çalıĢacak baĢka kullanıcıların
hizmetine yöneltebilmeleri, sistem yapımcılarının çözmesi gereken baĢlıca sorunlardan
biri olmuĢtur.
Ana iĢlem birimi ve ana bellek, altmıĢlı yıllardan baĢlayarak, yetmiĢlerin
ortalarına kadar, toplam eder içindeki oranları nedeniyle, bir sistemde bölüĢülmeleri
amaçlanmıĢ ilk kaynaklardır. Günümüzde ise, mıknatıslı depolama birimleri, satır
yazıcılar gibi, diğer birimlere oranla pahalı
olmaya
baĢlayan
kaynakların
bölüĢülmesine çalıĢılmaktadır (ġekil-3).
12
1960'lar
Kullanıcılar
Veri
Depolama
Birimleri
AİB
+
Ana
Bellek
Eğilim
Bilgisayar
1980'ler
Bilgisayar
Bilgisayar
ġekil-3. Bilgi ĠĢlem Ortamının Evrimi
Bilgisayar sistemlerindeki kaynak bölüĢüm sorunu, ekonomik gerekçeler kadar,
uygulamaların zorunlu kıldığı nedenlere de dayanmaktadır. Örneğin rezervasyon, stok
denetimi, banka hesapları vb. uygulamalarda, birçok kullanıcının ortak bir veri kümesini
bölüĢmesi gereklidir. Süreç denetimi gibi, eĢzamanlı iĢlevlerin birlikte yürütülmesi
13
gereken uygulamalarda ise, bilgisayar sistemi, paralel çalıĢan bağımlı/bağımsız birçok
görev arasında bölüĢülür.
Bilgi iĢlem ortamının kabaca çizdiğimiz bu evrimi nedeniyle, iĢletim sistemleri,
sürdürdükleri kaynak denetim iĢlevinin yanısıra, bu kaynakları kullanıcılar arasında
dengeli olarak bölüĢtürme görevini de üstlenmiĢtir. Bu aĢamayı da gözeterek, iĢletim
sisteminin tanımını "bir bilgisayar sisteminde, kullanıcılar ile iletiĢim kurarak, istenen
hizmetleri karĢılayacak kaynakları ise yöneltecek, bu kaynakların düzen içinde, uyumlu
çalıĢmalarını sağlayacak ve sistem kaynaklarını, sistemin karĢılaması beklenen amaç
yönünde kullanıcılar arasında bölüĢtürülecek araç" olarak tamamlıyoruz.
1.5. Job (ĠĢ)
Kullanıcıların, bilgisayar sisteminde bağımsız bir bütün olarak iĢlenmesini
istedikleri, iĢletim sisteminin de diğerleri ile iliĢkilendirmeden ele alacağı hizmet
kümesi, iĢ olarak adlandırılır.
Bilgisayar sistemlerine sunulan iĢler, bir veya daha çok programın ayrı ayrı
uygulanacağı alt adımlardan oluĢabilir. Kullanıcılar, yalnız aynı iĢ içinde yer alan
adımları iliĢkilendirme olanağına sahiptir. Adımların uygulanıĢında izlenecek sıra,
kullanılacak kaynaklar, iĢ denetim dilleri veya iĢletmen komutları ile iĢletim sistemine
tanımlanır.
ĠĢler, genellikle adımların ard arda uygulanacağı biçimde düzenlenir. Her adım,
bir öncekinin sonuçlanması üzerine iĢletime girer. Ancak, kullandıkları fiziksel
kaynaklar yönünden çeliĢmeyen bağımsız adımların, paralel olarak uygulanabilmeleri de
olanaklıdır. Örneğin, delikli kartlar üzerinde hazırlanmıĢ bir programda kullanılan bazı
yordamların, mıknatıslı Ģeritte saklanan bir kaynak yordam kitaplığında bulunduklarını
düĢünelim. Derleme ve bağlama iĢlemleri sonunda elde edilen amaç programın iki kez,
iki bağımsız veri kümesi ile (delikli kart ve mıknatıslı tekerdeki bir kütük)
uygulanacağını varsayalım. Bir bilgisayar sisteminde bu iĢi çalıĢtırmanın en yalın yolu,
adımların sıradan iĢletilmesidir (ġekil-4a). Ancak, örnekteki derleme ve uygulama
adımlarının ayrı kaynaklar kullandıkları düĢünülürse, bu iĢin ġekil-4b'de gösterildiği
gibi, paralel çalıĢan adımlarla da düzenlenmesi olanaklıdır.
14
1.Adım
Derleme 1
Kaynak Program
A
Kaynak Yordam
Kitaplığı
A
2.Adım
Derleme 2
B
3.Adım
Bağlama
Amaç
Program P
4.Adım
1.veri
kümesi
P
K1
2. Veri
Kümesi
Sonuçlar
P
5.Adım
K2
ġekil-4a. Sıradan Uygulama Ġle ĠĢ Adımlarının Düzenlenmesi.
15
Derleme 1
Derleme 2
B
A+B
Bağlama
P
1.Veri
Kümesi
P
P
K1
Amaç
Program
2.Veri
Kümesi
K2
Sonuçlar
ġekil-4b. Paralel Uygulama Ġle ĠĢ Adımlarının Düzenlenmesi.
1.6. Task (Görev)
Bir bilgisayar sisteminde hizmet üretimi, bağımlı veya bağımsız birçok iĢlevin
birlikte yürütülmesiyle sağlanır. Örneğin, bir program derlenirken giriĢ-çıkıĢ
donanımından gelen uyarıları yanıtlamak, gerçek zaman saatinin uyarılarını izleyip,
zamanla ilgili sayıĢını yapmak, sistem iĢletmeninden gelecek komutları kollamak gibi
iĢlevleri paralel sürdürmek gereklidir. Bu nedenle sistemdeki AĠB'nin zaman zaman
yürütmekte olduğu iĢi bırakıp, daha öncelikli yeni bir iĢleve yönelmesi, sonra da
bıraktığı iĢe dönüp, iĢletimi kesildiği noktadan sürdürmesi zorunludur. Bu iĢleme
AĠB'nin anahtarlanması denir.
Anahtarlanmayı yapabilmek için;
a)AĠB'nin eski durumunun saklanması,
b)AĠB'nin durum yazmacının, diğer yazmaç vb. öğelerin yeni iĢlevi ilgilendiren
verilerle günlenmesi gerekir.
ĠĢletim sistemleri bu amaçla, birlikte yürütülecek her iĢlevin çalıĢma ortamını
tanımlayan bir yapı kurar. Bu yapıda AĠB'ni anahtarlamada kullanılacak verilerin
yanısıra, iĢlevi yürütmek için gereksinen kaynakların listesi ve çeĢitli sayıĢım bilgileri
bulunur.
16
1.Görevin
Uygulandığı
Program
2.ve3.Görevlerin Uygulandıkları Prog.
AİB
Program
Sayacı
...
Yapılar
Yazmaçlar
Durum Sözcüğü
Prog.Sayacı
1.görev
Yazmaçlar
2.görev
Yazmaçlar
3.görev
Veri
Alanları
ġekil-5. Bir ĠĢletim Sisteminde Görevlerin OluĢturdukları Ortam.
ĠĢletim sistemi açısından bakıldığında, AĠB'nin yöneltileceği çalıĢma ortamını
tanımlayan bu yapı, uygulanacak program ve ilgili veri alanları ile birlikte, sistemdeki
en küçük iĢletim birimini oluĢturur. Bu iĢletim birimi task (görev) olarak adlandırılır.
ġekil- 5' te bir sistemde birlikte çalıĢan üç görevin oluĢturdukları ortam gösterilmiĢtir.
Ġkinci ve üçüncü görevler aynı programı uygulamaktadır. AĠB ise üçüncü göreve
atanmıĢtır. Birinci ve ikinci görevlerin yapıları, iĢletimin bırakıldığı son durumu
saklamaktadır.
2. ĠĢletim Sistemi Türleri
ĠĢletim sistemi türleri;
a)Kullanıcılara sağladıkları çalıĢma ortamı,
b)Kullanıcıların sisteme eriĢim biçimleri,
c)Tasarım ve yapılarında izlenen yaklaĢımlara göre, birbirine dolaylı olarak
bağımlı üç boyut üzerinde incelenebilir. Bir iĢletim sistemi, ilk iki boyuttaki
özelliklerinden yalnız birini taĢıyabileceği gibi, bunlardan çeliĢmeyen birkaçını da
birlikte bulundurabilir.
2.1. ÇalıĢma Ortamına Göre Sınıflandırma
Günümüzdeki çoğu iĢletim sistemi kullanıcılara fiziksel sistemin görünümünü
aĢan çalıĢma ortamları hazırlamaktadır. Örneğin ana belleğin kapasitesi veya sistemdeki
kart okuyucu, satır yazıcı sayısı, gerçek sistem görünümünün çok üzerinde
olabilmektedir. Kullanıcıların iĢ denetim dilleri ve programları aracılığı ile
tanımladıkları, sınırlarını çizdikleri bu çalıĢma ortamları, bilgisayar sisteminin
17
görünümünü aĢsın veya aĢmasın, "Görüntü Sistemler" olarak adlandırılır. ĠĢletim
sistemi, görüntü sistemleri, gerçek sistemin kaynakları ile kurup çalıĢtıran aracılar
olarak da tanımlanabilir.
Bir iĢletim sistemi, aynı anda yalnız bir görüntü sistem kurma olanağını
sağlıyorsa, bu sistemin tek iĢ düzeninde (monoprogramming) çalıĢtığı, eĢ zamanlı birçok
görüntü sisteminin kurulmasına olanak sağlıyorsa, çok iĢ düzeninde
(multiprogramming) çalıĢtığı söylenir. Birlikte çalıĢan görüntü sistemleri, AĠB dıĢındaki
kaynaklar için kesiĢebiliyorsa, iĢletim sistemi eĢzamanlı kaynak bölüĢümüne olanak
tanımaktadır. Bunların yanısıra, bir iĢletim sistemi kurulan herhangi bir görüntü
ortamının birden çok AĠB içermesine izin veriyorsa, bu sistemde ayrıca, çok görevli
iĢlem (multi-tasking) yapıldığı söylenir.
2.1.1 Tek ĠĢ Düzeni (Monoprogramming)
Tek iĢ düzeninde çalıĢılan bir sistemde, bir anda yalnız bir görüntü ortam
kurulduğundan, kullanıcı sistemin kaynaklarını tümü ile kullanabilir. ĠĢletimde oluĢan
hatalar baĢka bir kullanıcıya yansımayacağı için, korunma önlemleri, sadece iĢletim
sistemi ile kullanıcı arasında öngörülür. Bu nedenlerle tek iĢ düzeninde kaynak atama,
sistem bütünlüğünü koruma gibi sorunlar, yalın biçimde çözülebilir. Ancak kurulan
görüntü sistemler, çoğu kez gerçek görünümünün altında kalacağından, bu iĢletim
sisteminin verimlilik düzeyi de düĢüktür.
2.1.2 Çok ĠĢ Düzeni (Multiprogramming)
Çok iĢ düzeni baĢlangıçta, AĠB'nin boĢ olarak beklediği süreleri değerlendirmek
için tasarlanmıĢtır. Sistemde çalıĢan herhangi bir iĢ, bir giriĢ/çıkıĢ, bir zaman uyumu vb.
nedenle beklemeye geçtiğinde AĠB'nin baĢka bir iĢe baĢlaması ve böylece bu pahalı
birimin kullanım düzeyinin yükseltilmesi amaçlanmıĢtır. Genellikle AĠB ile giriĢ/çıkıĢ
birimlerinin çalıĢma hızları arasındaki fark büyüktür. Örneğin, dakikada 300 kart
okuyabilen bir okuyucudan giriĢ yapmak isteyen bir program;
60 / 300 saniye = 200 milisaniye
beklemek zorundadır. Bir sistemde ortalama iĢlem hızının 2 ile 5 mikro saniye arasında
olduğu varsayılırsa, bu bekleme süresi içinde;
200 / 2 * 1000 = 100000 veya 200 / 5 * 1000 = 40000
(1/1000 sn = 1 mili sn, 1/1000 mili sn = 1 mikro sn, 1/1000 mikro sn = nano sn)
komut iĢlemek olanaklıdır.
Çok iĢ düzeninin ilkelerini incelemek üzere, bir sistemde, üç iĢin paralel çalıĢtığı
bir yapıyı düĢünelim (ġekil-6). Her iĢ, AĠB'ni bir süre kullandıktan sonra (a (kullanıcı,
kez)), bir giriĢ/çıkıĢ (g (kullanıcı, kez)) baĢlatmaktadır. Bu giriĢ/çıkıĢ sonunda AĠB boĢta
ise, kullanıcı yeniden çalıĢmaya baĢlamakta (örneğin ikinci kullanıcı, birinci g/ç sonu:
g21 a22 ), eğer AĠB baĢka bir iĢe atanmıĢ ise, kullanıcı bu birimin serbest kalmasını
18
bekleyip (örneğin birinci kullancı, birinci g/ç sonu: g11 b11) AĠB'ne daha sonra sahip
olmaktadır (b11 a12 ). ġekil-6'da I ve II ile gösterilen taralı alanlar AĠB'nin atanacağı iĢ
kalmadığında, boĢ geçen süreleri göstermektedir.
Bu sistemde birinci iĢin toplam iĢletim süresi,
a
ij
j
g
b
1l
l
k
1k
bağıntısı ile gösterilir. Bu iĢin sonuçlanması, sistemde çalıĢan diğer iĢler nedeniyle
b
1l
l
kadar gecikmeye uğramıĢtır.
AĠB, uygulanacak baĢka iĢler bulunduğundan
a
a
2j
3k
süresi boyunca
çalıĢmıĢtır. Bunun yanısıra, ikinci ve üçüncü iĢler, birinci iĢin kullandığı yan birimler
dıĢında kalanları da paralel çalıĢtırdıklarından, sistemin toplam kullanım düzeyi
artmıĢtır.
Tek iĢ düzeni düĢünüldüğünde, çok iĢ düzeni iĢlerin çalıĢma sürelerini, AĠB'ni
bekleme süresi kadar arttırmaktadır. Ancak, sistemde aynı anda birçok iĢ paralel
çalıĢtığından, bazı iĢler de görüntü ortamlarına kavuĢtukları andan baĢlayarak,
diğerlerinin sonuçlanmasını beklemeden iĢletimlerini tamamlayabilirler. Oysa ġekil-6'da
verilen örnek, tek iĢ düzeninde çalıĢan bir sistemde uygulansaydı, birlikte sunulan üç
iĢten yalnız biri uygulanabilecek, diğerleri sıra ile bir öncekinin bitmesini bekleyecekti.
Bu nedenle, iĢlerin sonuçlanmaları için gereken sürenin, tek iĢ düzenine göre ortalama
olarak daha düĢük olması doğaldır. Birlikte çalıĢacak iĢlerin seçimi, bu sürenin, tek iĢ
düzenine göre ortalama olarak daha düĢük olması doğaldır. Birlikte çalıĢacak iĢlerin
seçimi, bu sürenin artıp, eksilmesindeki baĢlıca etkendir.
AİB'ni Bekleme
Kullanıcılar
a11
AİB
b11
1
g
G/Ç
2
G/Ç
11
g12
a 21
AİB
b21
a 12
a 22
g21
AİB
b
a 13
a 23
g
22
b
a 31
3
b12
32
g31
31
G/Ç
I
II
AİB Boş
19
Zaman
T
ġekil-6. Çok ĠĢ Düzeninde AĠB Kullanımı.
2.1.3. Çok Görevli ĠĢlem (Multitasking)
Bir sistemde bağımsız çalıĢabilen en küçük iĢletim birimi olarak tanımlanan
görev, kullanıcıların bilgisayar sistemine sundukları iĢlerin yürütülmesini sağlayan temel
araçtır. Bir iĢin sistemde çalıĢması, iĢletim sisteminin bu iĢe en az bir görevi koĢması ile
gerçekleĢir. Adımları sıradan uygulanacak bir iĢ (ġekil-4a), sırası ile derleme, bağlama,
uygulama adımlarını karĢılayan programları çalıĢtıracak tek bir görev tarafından
yürütülebilir. Ancak, iĢteki bazı adımları paralel olarak uygulamaya yöneldiğimizde
(ġekil-4b), birlikte yürütülecek her adım için ayrı bir görevin kullanılması gerekir. Böyle
bir çalıĢma ortamını kurma olanağını sağlayan iĢletim sistemleri, çok görevli iĢlem
yapan (multitasking) sistemler olarak tanımlanır.
ĠĢletim sistemleri, bağımlı ve bağımsız birçok iĢlemi birlikte yürütmekle
yükümlü olduklarından, doğal olarak çok görevli yapıda çalıĢırlar. Bu görevlerden
yalnız sınırlı bir kesimi, kullanıcıların iĢlerini yürütürler. ĠĢletim sistemleri içinde
çalıĢan görevler, ya da ayrı kullanıcılara hizmet üreten tek tek görevlerden oluĢan bir
topluluk, bir bilgisayar sisteminde çok görevli iĢlem yapıldığı anlamını taĢımaz. ġekil7'de birlikte çalıĢan iki kullanıcının (çok iĢ düzeni) oluĢturdukları ortam gösterilmiĢtir.
Birinci kullanıcı, uygulama adımını tek bir görevle yürütmektedir. Ġkinci kullanıcı ise
(ġekil-4b'de iĢlenen örnekte olduğu gibi), ilk iki derleme adımını birlikte yürüterek, çok
görevli iĢlem yapmaktadır. Bu kullanıcı, derlemeler bittiğinde, bağlama sürecini tek bir
görevle (birinci kullanıcı gibi) gerçekleĢtirecektir. Daha sonra, uygulama adımlarını
paralel yürütmek isterse, yeniden çok görevli bir ortam kuracaktır.
Çok görevli iĢlemde, kullanıcıların birlikte çalıĢtırabilecekleri görev sayısı,
iĢletim sistemi içinde görevler için öngörülen yapı sayısı ile sınırlıdır. Ancak bu üst
sınır, çoğu uygulama için yeterlidir. Ayrıca, birlikte çalıĢacak görev sayısı, kullanılan
diğer kaynaklar nedeniyle de, çoğu kez, iĢletim sisteminin izin verdiği sayının çok
altında kalır.
20
Görevler
İş Adımları
3
2
1.İş
1.Kullanıcı
1
3
2
gi
g1
Uygulama Derleme
4
Gerçek Zaman
Saati
gj
gk
2.Kullanıcı
1
g1
2.İş Uygulama Bağlama Derleme Derleme
g2
gm
İşletim
Sistemi
İşletmen
iletişimi
Görev
Yönetici
ġekil-7. Çok Görevli ĠĢlem
2.2. Sistem Kullanım Biçimine Göre Sınıflama
Bir bilgisayar sisteminde hizmet üretim süreci;
hazırlık + sunuş + işletim + sonuçlama
olarak tanımlanan evrelerden oluĢur. ĠĢletim sistemlerinde, iĢletim dıĢında kalan
evrelerin düzenleniĢ biçimleri, kullanıcıların bilgisayar sistemine nasıl eriĢeceklerini,
gereksedikleri hizmeti alırken nasıl davranacaklarını, doğrudan belirleyen etmenlerdir.
Bir iĢte, çalıĢma ortamının hazırlanması, uygulanacak programın iĢletim sistemine
aktarılması ve sonuçların kullanıcıya iletilmesinde benimsenen yaklaĢımlara göre,
iĢletim sistemleri;
a) AdanmıĢ iĢlem (Dedicated Processing),
b) Toplu ĠĢlem (Batch Processing),
c) EtkileĢimli iĢlem (Interactive Processing),
yapan sistemler biçiminde sınıflanmaktadır.
2.2.1. AdanmıĢ ĠĢlem (Dedicated Processing)
AdanmıĢ iĢlem, bilgisayar sisteminin belirli bir süre için, tümüyle bir
kullanıcının hizmetine verildiği çalıĢma türüdür. Ġlk kuĢak bilgisayar sistemlerinde ve
yetmiĢli yılların minibilgisayarlarında yaygın olarak kullanılmaya baĢlanmıĢtır.
Günümüzde kiĢisel bilgisayarlar ile yeniden gündeme gelen bu çalıĢma türü, kullanıcıya,
iĢin her adımını izleyip, elde edilen sonuçlara göre, iĢ akıĢını dinamik biçimde
yönlendirme esnekliğini sağlar. Örneğin metin düzenleme, derleme ve uygulama
adımlarını içeren bir iĢte (ġekil- 8), kullanıcı kaynak program ile verilerini metin
düzenleyiciyle günleyip, düzeltebilecek, derleme aĢamasına hatasız olduğuna inandığı
programı sunacaktır. Derleme veya uygulama adımında herhangi bir aksama olduğunda,
21
yeniden önceki adımlara dönüp, gereken düzeltmeleri yapması olanaklıdır. Kullanıcı,
bilgisayar sistemi ile karĢı karĢıya bulunduğundan, gereksinim duyduğu denetim
komutları yalın ve az sayıdadır.
AdanmıĢ iĢlem, kullanıcılara etkin bir çalıĢma ortamı sağlamasına karĢın, sistem
kullanım düzeyinin çok düĢük kalması nedeniyle, bilgisayar sistemlerinin görünümleri
büyüdüğünde, çok pahalı bir yaklaĢım olmaktadır.
Metin
Derleme
Uygulama
Düzenleme
Kullanıcı
ġekil-8. AdanmıĢ ĠĢlemde ĠĢ AkıĢı.
2.2.2. Toplu ĠĢlem (Batch Processing)
Bir bilgisayar sisteminde iĢlerin akıĢını hızlandıracak en etkin önlem, uygulama
sürecinin her adımında yinelenen hazırlanıĢ ve sunuĢ evrelerinde tüketilen süreleri
kısaltmaktır. Bu da, gereksinen çalıĢma ortamının önceden planlanıp, düzenlenmesi ve
doğrudan insan etkeninin katılmadığı, otomatik bir iĢ akıĢ mekanizmasının kurulmasıyla
gerçekleĢtirilebilir. Toplu iĢlem bu ilkelerin uygulandığı ilk çalıĢma düzenidir.
Bu çalıĢma düzeninde, iĢteki adımlar, tüketilen kaynaklar, iĢletimde oluĢabilecek
koĢullara göre izlenmesi gerekecek yollar, iĢ sisteme aktarılmadan önce kesinlikle
belirlenir. Kullanıcı iĢ tanımını, programlarını, verilerini bilgisayar sistemine topluca
aktarır (ġekil 9). ĠĢ denetim dilleri, kullanıcının iĢini dolaylı yoldan yönetebilmesi için,
bu çalıĢma düzeninin zorunlu kıldığı araçlardır.
22
2. Adım
Hazırlama
1. Adım
Son Adım
Sonuçlanma
3. Adım
İş Akış Dili
Kullanıcı
ġekil-9. Toplu ĠĢlemde ĠĢ AkıĢı
Toplu iĢlem yapılan sistemlerde kullanılan en yaygın giriĢ birimi, kart
okuyuculardı. Günümüzde, disket birimlerinin delikli kartların yerini alması, mantıksal
açıdan eĢdeğerli sayılabilecek bu birimlerin de, toplu iĢlem düzeninin giriĢ birimleri
arasında sayılmalarını gerektirmektedir. Bunların dıĢında, birçok iĢi baĢka bir sistemde
mıknatıslı ortama aktararak (örneğin mıknatıslı Ģerit), bilgisayar sistemine yığılmıĢ ve
hızlı okuma yapabilen giriĢ uçlarından sunan çeĢitli sistemlerde bulunmaktadır. Uzaktan
iĢ giriĢi (Remote Job Entry) toplu iĢlem yapılan bir sisteme uzak bir noktadan iĢ sunma
ve çıktıları uzak bir yazıcıdan alma olanağı sağlayan eriĢim biçimine verilen addır.
Toplu iĢlem, bilgisayar sistemlerinin daha verimli kullanılmalarını sağlayarak, iĢ
baĢına düĢen sistem giderlerinin azalmasına yol açmıĢtır. Bu olumlu yönün yanısıra,
toplu iĢlemin sakıncalı sayılabilecek iki yönü bulunmaktadır. Bunlardan ilki; iĢ
yönetiminin, durgun ve iĢ denetim dilinin olanaklarıyla sınırlı bulunmasıdır. Kullanıcı,
iĢletimde oluĢan ve öngörmediği durumları çözümlemek için, iĢin sonuçlanıp kendisine
ulaĢmasını beklemek zorundadır. Doğru bir sonuç alabilmek için, iĢi yeniden sisteme
vermesi gerekmektedir. Ġkinci sakınca, sonuçlanma evresinden kaynaklanmaktadır.
Çoğu iĢletim ortamında iĢler sonuçlanmıĢ olsalar bile, çıktıların kullanıcıya ulaĢması
dakika, saat ile ölçülebilen düzeye çıkabilmektedir.
2.2.3. EtkileĢimli ĠĢlem (Interactive Processing)
EtkileĢimli iĢlem kullanıcılara, iĢlerini dinamik biçimde yönlendirme, yapılan
uygulamanın sonuçlarını aracısız elde edip, hızla önlem alma olanağını sağlayan çalıĢma
türüne verilen addır. Bu yaklaĢımla yönetilen bilgisayar sistemlerinin bir baĢka özelliği
de, birlikte çalıĢacak kullanıcı sayısının yüksek olabilmesidir.
Zaman bölüĢümü (Time Sharing), "kullanıcılara bir bilgisayar sisteminde tek
baĢına çalıĢıyormuĢ izlenimi veren" ve bu sistemi birçok uygulama arasında bölüĢtüren,
etkileĢimli iĢlem yaklaĢımına verilen addır.
EtkileĢimli iĢlemde, hizmet üretim süreci;
23
a) ĠĢlenecek bilginin (transaction) sisteme yöneltilmesi,
b) ĠĢletim için beklemesi,
c) ĠĢletim,
d) Sonuçların dökümü,
e) Kullanıcının düĢünme süresi,
biçiminde beĢ evreye ayrılır (ġekil-10).
İşletim için
Bekleme
İşletim Dilimleri
İşlenecek
Bilginin
Girilmesi
İşletim Evresi
Düşünme
Süresi
Sonuçların
Dökümü
Yanıt Süresi
İşlenecek
Bilginin
Girilmesi
Bir İşletim Süreci
ġekil-10. EtkileĢimli ĠĢlemde ĠĢletim Süreci
ĠĢlenecek bilginin girilmesinden baĢlayarak, sonuçların dökümüne kadar geçen
süreyi sistemin yanıt süresi olarak adlandırıyoruz. ġekil-10'dan görüleceği gibi yanıt
süresi, iĢletim için gereksenen süre kadar (iĢletim dilimlerinin toplamı), iĢletim evresine
geçmek için beklenen süreye ve iĢletim dilimleri arasında AĠB'nin diğer görevlere
yöneltildiği sürelere de bağlıdır. EtkileĢimli iĢlemde, iĢletim sisteminin baĢlıca
iĢlevlerinden biri "bu dilimlerin, kullanıcıların hiçbirini fazla bekletmeyecek biçimde"
dağılmasını sağlamaktır.
Yanıt süresi için, kesin bir üst sınırın çizildiği etkileĢimli uygulamaları, Gerçek
Zamanlı (Real Time) olarak niteliyoruz. Veri toplama, süreç denetimi gibi, fiziksel
sistemlerin izlenmesi, yönetilmesine iliĢkin uygulamaların yer aldığı bu iĢlem türünde,
yanıt süreleri çoğunlukla mikrosaniye, milisaniye, saniye ile ölçülen kısa dilimlerle
sınırlıdır. Kullanılan zaman birimi ne olursa olsun bu sistemlerin temel özelliği, istenen
hizmeti, önceden belirlenen süre içinde gerçekleĢtirmeye çalıĢmaktır. Ancak
milisaniyenin altında tutulması gereken yanıt süreleri söz konusu olduğunda, günümüz
bilgisayar teknolojisinin sınırları zorlandığından, çok özel yaklaĢımların benimsenmesi
gerekmektedir. Bu tür sistemlerin yapıları, doğal olarak, genel amaçlı kullanıma açık
olanlardan farklıdır.
2.3. Yapılarına Göre Sınıflama
ĠĢletim sistemlerini gerçekleĢtirirken benimsenen ilkeler, bu sistemleri
sınıflamada kullanılabilecek ölçütlerdir. Örneğin, sistemde görevlerarası zaman
uyumunda uygulanan yaklaĢımlara göre, iĢletim sistemlerini yapılarına göre iki grupta
toplamak olanaklıdır;
24
a) Ġletiye dayalı sistemler (message oriented systems),
b) Yordam çağırmaya dayalı sistemler (procedure oriented systems),
Bunun dıĢında sistemde temel birim varsayılan öğeler üzerinde (örneğin görev,
iĢ, kütük, program, vb.) yapılan iĢlemler de, ayırıcı etken sayılmaktadır.
3. ĠĢletim Sistemlerinde Temel ĠĢlevler
ĠĢletim sistemlerinin temel iĢlevleri;
a) Yazılım-donanım bütünlüğünün sağlanması,
b) Kaynakların yönetimi,
c) Kullanıcılar ile sistem arasındaki iliĢkinin,uyum ve düzeninin kurulması,
diye üç ana grupta toplayabiliriz.
3.1. Yazılım-Donanım Bütünlüğünün Sağlanması
Donanım üzerindeki denetim iĢlevleri ve çevre birimlerinin yönetimi, çekirdek
sistem denilen, temel yazılım katmanı tarafından yürütülmektedir. Bu çekirdek,
donanım ve yazılım arasındaki geçiĢi, kaynaĢmayı sağlayarak, daha üst katmanlara,
bilgisayar sistemini düzenli, yalın kurallar içinde yönetilen bir bütün olarak yansıtma
görevini üstlenmiĢtir. Örneğin, verilerin çevre birimleri ile ana bellek arasında nasıl
aktarıldığı, program ya da donanımda oluĢan aksamaların nasıl yakalanıp iĢlendiği, bu
katmanın üzerinde yer alan kesimlere yansımayan iĢlemlerdir.
Bilgisayar sistemlerinde yazılım ile donanım arasındaki iletiĢim, yazılımdan
donanıma doğru sistemin temel komutları, donanımdan yazılıma doğru da uyarılar yolu
ile kurulur. AĠB'nin çözüp çözüp uyguladığı sistem komutları, donanımı denetleyen
temel uyarıların üretilmesini sağlar. Sistemde var olan donanım birimleri ise, sonucu
bilgisayar sistemindeki uygulamayı etkileyecek oluĢumları, uyarılar biçiminde sisteme
yansıtırlar. Örneğin satır yazıcının, bir satır yazdıktan sonra serbest duruma geçmesi,
iĢletmen ucundan girilen bir karakterin, ana sisteme aktarılmaya hazır duruma gelmesi,
AMB'nin bir iĢlemi tutarsız sonuçlandırması vb. olaylar uyarılar biçiminde AĠB'ne
aktarılırlar. Çekirdek sistemin bu uyarıları yakalayıp, yorumlaması ve beklenen hizmeti
üretecek yordama yöneltmesi gerekir.
Bir bilgisayar sisteminde, donanımdan kaynaklanan uyarılar, yazılıma iki yoldan
yansıtılır. Bunlardan birincisi; bu uyarıları özel yazmaçlarla saklayıp, çekirdek sistemin,
gerekli gördüğü zaman bunları incelemesini beklemektir. Diğeri ise, AĠB'ni,
uygulamakta olduğu programı bırakarak, bu yeni olayı iĢleyecek yazılıma yönelmeye
zorlamaktır.
3.2. Kaynakların Yönetimi
ĠĢletim sistemlerinde, kaynakların yönetimi baĢlığı altında toplanan kesim,
kaynakların düzenlenmeleri ve bölüĢülmelerini amaçlayan yazılımın incelenmesine
yöneliktir. Bilgisayar sistemlerinde yer alan fiziksel ve mantıksal kaynaklar hem nitelik,
25
hem de nicelik yönünden farklı olduklarından, herbirinin yönetiminde benimsenen
yaklaĢımlar da ayrıdır. Ancak her kaynak yönetici:
a) kaynağın durumunu izleyen,
b) kime, ne zaman, ne süre ile atanacağını saptayan,
c) kullanıma hazır duruma getiren,
d) gerektiğinde geri alan iĢlevlerden oluĢur.
Fiziksel kaynaklar:
a) istenildiğinde bir kullanıcıdan geri alınıp, baĢka birine yöneltilebilenler,
b) doğası nedeniyle, kullanımı her zaman devredilemeyenler olmak üzere,
iki grupta toplanabilir. AĠB ve ana bellek ilk grup, satır yazıcı ve kart okuyucu ikinci
grupta yer alan kaynaklar için verebileceğimiz örneklerdir.
Fiziksel kaynakların gerçek anlamda eĢzamanlı bölüĢümü, hiçbir zaman söz
konusu değildir. Bir donanımın, sınırlı sürelerle birden fazla kullanıcının hizmetine
verilmesini, baĢka bir deyiĢle, bir kullanıcının belirli bir birimden beklediği tüm hizmeti
almadan, bu kaynağın baĢka birine yöneltilmesini, eĢzamanlı bölüĢüm diye
adlandırıyoruz. EĢzamanlı bölüĢüm, yalnız AĠB ve ana bellek gibi yeniden kullanılır
birimler için olanaklıdır. Ancak, böyle bir kaynağı kullanıcılar arasında
anahtarlayabilmek için bazı önlemler almak, düzenlemeler yapmak zorunludur. Örneğin,
AĠB'deki program sayacı, durum belirteçleri, genel amaçlı yazmaçlar kullanıcıya özgü
verileri içerirler. AĠB’nin bölüĢülebilmesi için, bu yazmaçların yeni kullanıcının verileri
ile günlenmeleri ve eski içeriklerinin saklanması gereklidir.
Satır yazıcı gibi, istenildiğinde geri alınamayan (eĢ zamanlı bölüĢülemeyen)
kaynaklar için de, yazılım yolu ile eĢdeğerli birimler yaratmak olanaklıdır. Böylece her
kullanıcı, kendi satır yazıcısını, kart okuyucusunu kullanabilir. ĠĢletim sisteminin,
"görüntü" diye nitelendirilen bu kaynakları da yönetmesi ve görüntü kaynak-fiziksel
birim iliĢkisini kurması gereklidir.
Yazılım nitelikli kaynakların eĢ zamanlı bölüĢümü, programların: a) yeniden
girilir nitelikte (reentrant) olmalarına, b) herkesce bilinen, öğrenilebilen adlarla
çağılmalarına bağlıdır. Ġlk özellik, çeĢitli programlama teknikleri ile kullanıcılar,
derleyiciler tarafından sağlanabilir. Ancak adlandırma sorunu, fiziksel kaynaklarda
olduğu gibi, iĢletim sisteminin yükümlülüğündedir. BölüĢülmesi istenen yazılım,
sistemin sürekli birleĢenleri arasında sayılıyorsa, baĢka bir değiĢle herhangi bir kullanıcı
tarafından rastgele zamanlarda yaratılıp, yok edilmiyorsa, tüm kullanıcılarca bilinen
ortak bir isimle çağırılabilir. Örneğin kimi sistemde derleyiciler, matematiksel ve
istatistiksel iĢlevler vb. yazılım, ana bellekte aynı isimle, birçok kullanıcı tarafından
eĢzamanlı bölüĢülmektedir. Bir sistemde bölüĢülen yazılımın, birbirinden habersiz
kullanıcılar tarafından, dinamik olarak yaratılıp, yok edilmesi istenirse, iĢletim
sisteminin bu oluĢumu izleyecek, gereken iliĢkileri kuracak iĢlevleri de içermesi gerekir.
Günümüzde, bedeli yüksek olan bu seçeneği uygulayan sistem sayısı çok sınırlıdır.
26
Bir bilgisayar sisteminde belirli bir süre kullanılması amacıyla atanabilecek
cinsten her türlü yapıta KAYNAK adı verilmektedir. Tipik bir sistemde bu yapıtlar
Ģunlar olabilir;
- K tane AĠB (CPU)
- L byte'lık bellek
- M tane disk
- N tane manyetik teyp
- P tane satır yazıcı
- Q tane kart okuyucusu ve yazıcısı
- R tane terminal
... vb.
ĠĢletim sistemleri açısından bir bilgisayar sisteminin kaynakları dört ayrı grupta
toplanabilir. Bunlar;
1) Bellek (Ana bellek)
2) AĠB (CPU)
3) Yan-üniteler (yazıcılar, terminaller, diskler, vb.)
4) Bilgi (Files, Data-Bases)
Bir bilgisayar sisteminin kaynaklarının, o sistemin performansını en yüksek
düzeyde tutabilecek bir Ģekilde paylaĢımlı olarak kullanılmasını sağlayan mekanizmaya
YÖNETĠM adı verilir.
Bir sistemin performansı temel olarak beĢ ayrı kriterle ölçülür. Bunlar;
1) Verimlilik: ĠĢletim sistemleri genellikle karmaĢık programlardan oluĢmuĢtur. Bu
programların, yönetimini üstlendikleri sistem kaynaklarını kullanma oranı ne kadar
düĢük olursa, sistemin verimliliği de o derece yüksek olur.
2) Güvenilirlik: Sistem yönetimi, en azından üstünde kurulu olduğu donanım kadar
güvenli olmalıdır. Donanım veya yazılım yönünden doğacak sorunları sezebilmeli ve bu
sorunlardan doğacak zararları en aza indirmelidir.
3) Koruyuculuk: Yönetim bir kullanıcının, ki bu bir program da olabilir, yapacağı
hataların diğer kullanıcıları hiçbir Ģekilde etkilememesini sağlayabilmelidir.
4) Sezdiricilik: Genellikle kullanıcıların sistemden isteklerinin neler olduğunu sezmek
veya kestirmek kolay olmamaktadır. Ancak, kullanıcıların isteklerinin belirli süreler
içinde büyük farklılıklar göstermediği de söylenebilir. Örneğin, kullanıcı sisteme bir iĢ
girdiğinde, o iĢin kabaca ne zaman sonuçlanabileceğini kestirebilmelidir.
5) ElveriĢlilik: Kullanıcıların bir sistemin kaynaklarını paylaĢımlı olarak kullanmaları,
onların kendi istekleriyle değil de sistemin onlardan istediği ekonomik bir
zorunluluktur. Dolayısıyla sistem yönetimi, kullanıcıya verilen servisin kolay elde
edilebilir, yani elveriĢli olmasını da sağlamalıdır.
27
Bir iĢletim sisteminin yönetim fonksiyonlarını temel alarak dört ayrı gruba
ayırabiliriz. Bunlar;
1) Kaynakların izlenmesi (KĠ), kaynağın statüsü, kullanıldığı yer, vb.
2) Kaynakların kullanım politikasının saptanması (KP), kim, ne zaman, ne
kadar?
3) Kaynakların atanması (KA)
4) Kaynakların kullanıcılardan geri alınması (KG)
dır.
3.2.1. Ana Belleğin Yönetimi
YetmiĢli yılların ortalarına kadar, ana bellek, bölüĢülür niteliği ve sistem
içindeki yüksek ederi nedeniyle, üzerinde yolun çalıĢma yapılan bir kaynak olmuĢtur.
Günümüzde, donanımın büyük ölçüde ucuzlaması, ana belleğin geçmiĢe göre daha yalın
yöntemlerle yönetilmesini olanaklı kılacaktır. Ancak, orta ve büyük boy birçok sistemin,
yapılmıĢ olan yatırımlar nedeniyle, geçmiĢ dönemin izlerini taĢıyacağı ve ana belleğin
yönetimi için benimsenmiĢ ilkelerin, daha bir süre yürürlükte kalacağı öngörülebilir.
ġimdi yönetim fonksiyonlarının bellek için ne anlam taĢıdıklarını inceleyelim.
1)KĠ: Belleğin hangi bölümlerinin kullanılmakta olduğunun ve kimler tarafından
kullanıldığının, ayrıca belleğin hangi bölümlerinin kullanılabilir durumda (FREE)
olduğunun izlenmesi.
2)KP: Eğer "Multi-Processing" yapılıyorsa belleğin hangi "Process"lere (görev veya iĢbirimlerine) ne zaman ve ne kadar bir süre için verilmesi gerektiğinin saptanması.
3)KA: Sistemdeki bir "Process" bellek isteğinde bulunduğunda "Kullanım Politikası"na
aykırı olmadıkça gereken atamanın saptanması.
4)KG: "Process"lerden, iĢlerinin bitiminde, onlara atanmıĢ bellek sahalarının geri alınıp,
o sahalarla ilgili statü değiĢikliklerinin yapılması.
Bellek ve AĠB yönetimleri birbirlerine sıkı bağlarla bağlanmıĢtır. Bir program
ancak belleğe yerleĢtirilmiĢ ise iĢlem görebilir. Dolayısıyla belirli bir süre için AĠB
denetimini ele geçiremeyecek bir programın bellekte tutulması, o bellek bölümünün
boĢu boĢuna harcanması demektir. Bir bilgisayar sisteminin en pahalı kaynaklarından
biri olan belleğin bu Ģekilde harcanmasını önlemek için iĢletim sistemi, daha doğrusu
bellek yönetimi, belleğin iĢlenebilir programlarla yüklü olmasını ve bellekte oluĢan
boĢlukların kullanılabilir bir durumda düzenlenmesini sağlamakla yükümlüdür. Bu ve
benzeri bellek yönetim sorunlarını çözmek için Relocation, Paging, Segmentation,
Partition, Allocation, Swapping, Overlaying gibi çeĢitli teknikler geliĢtirilmiĢtir. Ancak
bu tekniklerin bellek yönetimi açısından getirdikleri kolaylıkları ve uygunluğu gerek
28
donanım ve gerekse yazılım yönünden getirdikleri "OVERHEAD" lere karĢı tartıp,
bellek yönetimini kullanım amacına uygun bir Ģekilde düzenlemek gerekir. Ne var ki,
günümüze kadar ve halen yapılmakta olan araĢtırmalara rağmen sözünü ettiğimiz bellek
yönetim tekniklerinin karmaĢık bir sistem içinde nicelik olarak analiz edilebilmeleri ve
değerlendirilmeleri yapılamamaktadır. Bugün kendi sistemimizde uygulanmasını
gördüğümüz Paging-Relocation teknikleri dahi basit modeller ve Uygula-Gör
yaklaĢımıyla analiz edilip değerlendirilmektedirler.
3.2.2. Ana ĠĢlem Biriminin Yönetimi
Bir bilgisayar sisteminin en sık anahtarlanan kaynağı AĠB'dir. Bu birimin
atanacağı görev, ya bir kesilmeyi iĢlemek üzere donanım tarafından, ya da bir
uygulamayı yürütmek için iĢletim sistemi tarafından seçilir. Donanımca yapılan
anahtarlama, kesin ve bilgisayarın yapısıyla dondurulmuĢ bir sıradüzene bağlıdır. ĠĢletim
sisteminin bu görevler üzerindeki denetimi sınırlıdır. Ancak, iĢletim sistemi içindeki bir
iĢlevi ya da bir kullanıcının programını uygulamak üzere bekleyen görevlerin seçimi,
tümüyle yazılımın denetimindedir. Görev yöneticisi diye adlandırdığımız iĢletim sistemi
kesimi, AĠB'ni en öncelikli saydığı göreve atar. Bu yazılım ayrıca, çalıĢmak için
bekleyen görevlerin öncelikleri üzerinde düzenlemeler yaparak, AĠB'nin, sistemin
yönetildiği uygulama amacını karĢılayacak biçimde, bölüĢülmesine çalıĢır. Bu
sistemdeki görevler, yaratıldıkları andan baĢlayarak, yaĢam sürelerince : a) hazır, b)
çalıĢır, c) bekler diye adlandırılan durumlardan geçerek, iĢletimlerini sürdürürler (ġekil
11). Yaratılan her görev AĠB dıĢındaki kaynaklarına kavuĢunca, görev yönetici
tarafından seçilmek üzere, hazır durumdaki diğer görevlerin arasına katılır (a). AĠB'ne
kavuĢan bir görev (b), bir süre çalıĢtıktan sonra ya bir giriĢ/çıkıĢ yapmak üzere ya da
baĢka bir görevle zaman uyumu sağlamak için bekler duruma geçer (c) ve beklediği olay
geliĢince yeniden hazır görevler arasına döner (d). Birçok iĢletim sistemi, AĠB'nin hiç
giriĢ/çıkıĢ yapmayan bir görev tarafından uzun süre tutulmasını engellemek üzere,
görevleri yeniden hazır duruma döndüren (e) ve AĠB'ni baĢka bir göreve atayan önlemler
içerir.
Sonuçlanma
Başlama
(a)
(b)
Hazır
Çalışır
(e)
(c)
(d)
Bekler
29
ġekil-11. Görevlerin Durumları
ġimdi yönetim fonksiyonlarının AĠB için ne anlam taĢıdıklarını inceleyelim.
1)KĠ: O anda iĢlem gören "Process"lerin statülerinin izlenmesi, birden fazla AĠB'nin
kullanıldığı sistemlerde (Multi-Processor) her AĠB'nin statüsünün izlenmesi. AĠB
yöneticisinin kaynak izlenimi ile ilgili görevli kısmına Trafik Kontrolü adı
verilmektedir.
2)KP: Sisteme girilmesi istenilen iĢlerden hangilerinin sisteme girilebileceğine karar
verilmesi. Bu tip kararlar bir iĢ için istenilen kaynakların olup olmaması veye yeterli
olup olmaması göz önünde tutularak alınmaktadır. AĠB yöneticisinin bu görevle ilgili
kısmına JOB-SCHEDULAR adı verilmektedir. Eğer "Multi-Processing" söz konusu ise
hangi "Process"in AĠB'ni ne zaman ve ne kadar süre için kontrol altına alınabileceğinin
saptanması. Bu saptamayı da Processor-Schedular adını verdiğimiz mekanizma
yapmaktadır.
3)KA: "Processor-Schedular" politikasına uygun olarak seçilen ve sırasını beklemekte
olan "Process"lere AĠB kontrolünün verilmesi. Bu iĢlem de Dispatcher adı verilen bir
mekanizma tarafından yapılmaktadır.
4)KG: "Process"lerin AĠB gereksinmeleri karĢılandığında ve / veya "Process"lere atanan
zaman dilimlerinin bitiminde AĠB kontrolünün geri alınması.
ĠĢletim sistemlerini gerektiren nedenlerin baĢında AĠB hızı ile yan-ünitelerin
hızları arasında farklılık (uyumsuzluk) gelmektedir. Bu nedenle yan ünitelerle AĠB'nin
çalıĢtırılmasında paralelliğin kurulması ve dolayısıyla bir program g/ç iĢlemi yaparken,
diğerinin buna paralel olarak AĠB'ni kullanması sağlanmalıdır. Böyle bir paralelizmin
gerçekleĢtirilmesi oldukça karmaĢık yazılım ve donanım gerektiren bir iĢlemdir.
Paralelizm her ne kadar kaynakların optimum bir Ģekilde kullanılmasını amaçlıyorsa da,
örneğin yan-ünitelerin kullanımını optimize etmeğe çalıĢırken hiç g/ç iĢlemi istemeyen
programların AĠB gereksinimlerini karĢılamakta sorunlar yaratılabilir. ĠĢte bu ve benzeri
sorunları çözmeye yönelik olarak AĠB
yan üniteler paralelizmini sağlayacak
tekniklerin incelenmesi ve analiz edilmesi AĠB yönetimi ile ilgili çalıĢmaların temelini
oluĢturmaktadır.
3.2.3. Yan-Ünitelerin Yönetimi
1) KĠ: Sisteme bağlı bütün yan-ünitelerin (diskler, teypler, terminaller, kontrol üniteleri,
yazıcılar vb.) kullanılıp kullanılmadıklarını, eğer kullanılıyorsa kimler tarafından
kullanılıyor ve benzeri statü bilgilerinin tutulması ve izlenmesi. Bu iĢlem G/Ç Trafik
Kontrolü tarafından yapılmaktadır.
2) KP: Yan-ünitelerin en verimli bir Ģekilde kullanılmasını sağlayacak atama
politikasının saptanması ve yürütülmesi. Yan-ünitelerin paylaĢımlı kullanımını
sağlamak amacıyla bu üniteleri isteyen "Process"lerden hangilerinin, ne zaman ve ne
30
kadar bir süre için üniteleri kontrolleri altına alabileceklerine iliĢkin kararların alınması.
Bu iĢlemler G/Ç Scheduler mekanizması tarafından yapılmaktadır.
3) KA: "G/Ç Scheduler"ından alınan bilgilere göre yan-ünitelerin atanmalarının
yapılması ve g/ç iĢlemlerinin baĢlatılması. Bu iĢlemler de G/Ç Dispatcher mekanizması
tarafından yapılmaktadır.
4) KG: G/Ç iĢlemlerinin bitiminde söz konusu ünitelerin tekrar atanabilmeleri için "G/Ç
Scheduler" ına kazandırılması.
Yan-ünitelerin yönetiminde, bu ünitelerin çalıĢma prensipleri ve karakteristikleri
göz önünde tutulmalıdır. Çünkü kart okuyucuları, satır yazıcıları gibi üniteler paylaĢımlı
olarak kullanılamazlar. Dolayısıyla bu tip yan ünitelerin atanmaları tek bir "Process"e ve
sınırlı bir süre için yapılmalıdır.
Diğer taraftan diskler veya kontrol üniteleri gibi üniteler paylaĢımlı olarak
kullanılabilirler. Örneğin birbirinden bağımsız iki ayrı process aynı disk üzerindeki
bilgilere ve hatta aynı bilgilere aynı zamanda eriĢebilirler. Bu arada Ģunu belirtmek
gerekir ki, bir ünite paylaĢımlı kullanıma ne kadar elveriĢli ise o üniteyi yönetmek için
gereken teknikler ve yöntemler de o derece karmaĢık olmaktadır.
PaylaĢımlı kullanıma yatkın olmayan ünitelerin bu yeteneklerini
"GörüntüleĢtirme (Virtualize)" tekniği ile geliĢtirmek olasıdır. Bu teknik ile
process'lerden yan-ünitelere veya yan-ünitelerden process'lere aktarılması istenen
bilgiler process'lerin veya yan-ünitelerin o bilgileri görmek istedikleri Ģekilde transforme
edilip, örneğin disk gibi bir ortamda havuzlanmakta ve daha sonra buradan alınarak
istenilen process'lere veya yan-ünitelere gönderilmektedir.
Bilgisayar sistemlerinde kart okuyucu, kart delici ve satır yazıcı gibi yanünitelerin görüntüleĢtirilmesini ve satır yazıcı gibi yan-ünitelerin görüntüleĢtirilmesini
sağlayan mekanizmaya SPOOLING (Simultaneous Peripheral On-Line Operation) adı
verilmektedir. Bu mekanizmanın karmaĢık bir sisteme bağlı yan-ünitelerin yönetimi
açısından getirdiği kolaylıklar Ģöyle sıralanabilir ;
1) PaylaĢımlı kullanıma tam anlamıyla yatkın olmayan yan-ünitelerin paylaĢımlı
kullanımını sağlar,
2) Hız bakımından birbirinden çok farklı iki ünite arasındaki bilgi transferinin en
etkin bir Ģekilde yapılmasını sağlar (Örneğin; diskten satır yazıcısına veya kart
okuyucusundan diske bilgi transferinde olduğu gibi),
3) Kullanıcılardan gelen iĢlerin sisteme alınmasında elastikiyet kazandırır. ġöyle
ki, çok AĠB gereksinimi olan iĢlerle çok G/Ç gereksinimi olan iĢlerin Job-Scheduling
mekanizması aracılığıyla sisteme alınan iĢlerin homojenleĢtirilmesini sağlar.
3.2.4. Verilerin Yönetimi
Bilgisayar sistemlerinde, ana belleğin dıĢında saklanan ya da üretilen verilerin
bulunduğu mantıksal ortam, KÜTÜK diye adlandırılmaktadır. Verilerin yönetimi,
31
kullanıcı-kütük (program-veriler) ve kütük-çevre birimi (veriler-fiziksel giriĢ/çıkıĢ
birimleri) iliĢkisini kuran iĢlevlerden oluĢur.
Bu iĢlevler;
a) programlara mantıksal düzenleriyle yansıyan kütüklere eriĢimi sağlamak ve
kullanım, koruma önlemlerini almak,
b) kütüğün bulunduğu fiziksel ortamı saptamak, verilerin bu ortamdaki
konumunu belirlemek,
c) bu fiziksel birimden giriĢ/çıkıĢ yapmak,
d) gerekirse fiziksel birim üzerinde düzenlemeler yaparak, iletiĢim ve üretim
verimliliğini arttırmakla yükümlüdür.
ġimdi yönetim fonksiyonlarının bilgi için ne anlam taĢıdıklarını inceleyelim.
1) KĠ: Sistemde saklanmakta olan bilginin yerlerinin kimlere ait olduklarının, kullanım
Ģekillerinin ve benzeri bilgi statüsü bilgilerinin tutulup izlenmesi. Bir iĢletim sisteminde
bütün bu iĢleri yapmakla yükümlü mekanizmalar topluluğuna FILE SYSTEM (kütük
sistemi) adı verilmektedir.
2) KP: Sistemde saklanan bilgilerin kimler tarafından kullanılabileceğinin saptanması,
bu bilgilere iliĢkin koruma önlemlerinin sağlanması ve yürütülmesi (protection),
bilgilere eriĢim olanaklarının sağlanması.
3) KA: "Process"lere eriĢmek istedikleri bilgilerin yani kütüklerin atanması. Örneğin bir
kütüğün kullanıma açılmasında kullanılan Open File komutunda olduğu gibi.
4) KG: "Process"ler tarafından kullanılan bilgilerin derlenip, toparlanması ve tekrar
FILE sistemine kazandırılması.
Bir bilgisayar sisteminin kullanıcılara verebileceği en önemli hizmetlerden birisi
de kullanıcıların bilgilerini saklamak, bu bilgiler üzerinde düzeltme, ekleme ve eriĢim
olanaklarını sağlamaktır. Bütün bu hizmetler File Sistemi tarafından, kullanıcıyı
bilgilerin saklandığı yan ünitelerle mümkün olduğu kadar az muhatap kılarak
yapılmalıdır. Ne yazık ki, temelde çok basit ilkelere dayanan bilgi yönetimi (information
management) günümüze kadar gelen sistemlerde diğer yönetim fonksiyonlarına göre en
az ilgi uyandıran ve dolayısıyla en az iĢleneni olmuĢtur.
Aslında konunun kapsamı göründüğünden çok daha geniĢtir.
Bilgi yönetimi hiyerarĢik olarak üç ayrı seviyede incelenir. Bunlar;
1) File Yönetimi,
2) Data Yönetimi,
3) Data Base Yönetimi’dir.
32
Bu dersin kapsamı içine giren File Yönetimi, bilgilerin gerek yapısal ve gerekse
anlamları yönüyle ilgilenmeksizin saklama organları (disk, teyp vb.) üzerindeki
mantıksal organizasyonu ile ilgilidir.
Data yönetiminde ise, yönetim fonksiyonu datanın yapısıyla veya
yapılaĢtırmasıyla ilgilidir. Datanın taĢıdığı anlamla ilgilenmez. Örneğin Data Yönetim
sistemi kütüklerin belirli uzunluklardaki segmentlerden, recordlardan oluĢtuğunu bilir
ve hatta kullanıcının bunlar üzerinde iĢlem yapmasını sağlar. Ancak bu iĢlemlerin ne
anlam taĢıdıklarını veya niçin yapıldıklarını bilmez. IBM' in IMS-II adı altında
kullanıma sunduğu sistem Data Yönetim sisteminin bir örneğidir.
Data-Base Yönetim sistemi ise, hem bilginin yapısı ile hem de bilginin taĢıdığı
anlam ile yakından ilgilidir. Örneğin, THY'na ait data-base sistemine bir hostes "904
nolu seferde kaç yolcu var?" diye sorabilmektedir.
3.3. Kullanıcıların Yönetimi
Bilgisayar sistemine iĢ sunan bir kullanıcıya hizmet verebilmek üzere, önce bu
kullanıcının çalıĢma ortamını tanımlayan görüntü bir sistemin kurulması gereklidir.
ĠĢletim sisteminde iĢ yöneticisi diye adlandırılan kesim, AĠB dıĢında kalan kaynakların
yöneticileri ile iĢbirliği yaparak, bu görüntü sistemleri kurar. Böylece iĢi uygulamak
üzere yaratılan bir ya da daha çok görev, iĢletime hazır biçimde, görev yöneticinin
denetimine verilir. Görev yönetici, bunları önceliklerine göre seçerek çalıĢır duruma
getirir.
ĠĢ yöneticinin bir baĢka görevi de kurulmuĢ görüntü sistemlerin çalıĢmalarını
denetlemektedir. ĠĢletimi geciken kullanıcılar için, görevlerin önceliklerini değiĢtirmek;
iĢletimde dinamik olarak atanan kaynakların dengeli bölüĢümünü sağlamak, bu denetim
iĢlevleri içinde yer alır. Ayrıca, sisteme yeni bir iĢ sunulduğunda, eldeki kaynaklar bu
iĢin görüntü sistemini kurmaya yetmezse, çalıĢmakta olan daha az öncelikli iĢlerin
yeniden kullanılır kaynaklarını geri alıp (görüntü sistemlerini bozup) bu iĢe yöneltmek,
iĢ yöneticinin yükümlülüğündedir.
Bu çerçeveden de görülebileceği gibi bilgisayar sisteminden hizmet alan bir
kullanıcının yönetimi:
a)Görüntü sistemleri kurup, dengeli biçimde çalıĢtıran iĢ yönetimi,
b)AĠB'ni, kurulu görüntü sistemler arasında bölüĢtüren görev yönetiminden
oluĢan, karma bir yapıdır (ġekil-12).
33
1
1
2
İş Yönetimi
Görev
Yönetimi
AİB
m
n
Kullanıcılar
K.Y.
Görüntü Sistemler
ġekil-12. Kullanıcıların Yönetimi.
BÖLÜM 2
ÇEKĠRDEK SĠSTEM
4.GiriĢ
Donanım üzerindeki denetim iĢlevleri ve fiziksel birimlerin yönetimi, çekirdek
sistem tarafından gerçekleĢtirilmektedir. Çekirdek sistemin yürüttüğü iĢlevler arasında
kesilmelerin yönetimi, görev yaratma ve yoketme g/ç iĢlemlerinin sağlanması sayılabilir.
4.1. Kesilmelerin Yönetimi
Kesilme, donanımdan kaynaklanan bir uyarı sonucunda AĠB'nin yürütmekte
olduğu görevi bırakıp, uyarıyı üreten donanıma hizmet verecek göreve anahtarlanmasına
yol açan olaydır. AĠB ile sistemdeki diğer donanım birimlerinin, zaman uyumsuz
çalıĢabilmelerini sağlayan bu mekanizma, bilgisayar sisteminde çözülmesi gereken iki
sorun yaratmaktadır:
a) kesilmeler çoğunlukla hızlı önlem alınmasını gerektiren fiziksel olaylardan
kaynaklandıklarından, görev anahtarlama iĢlemi en etkin biçimde nasıl
gerçekleĢmelidir?
b) uyarıları, bağlı oldukları olayların önceliğini yansıtan bir sıradüzene göre
iĢletime alırken, iĢlenmekte olan kesilme düzeyinin bütünlüğü nasıl korunabilir?
34
Çoğu bilgisayar sisteminde, kesilmeyi iĢleyecek görevin anahtarlanması,
donanım tarafından baĢlatılan, yazılım yolu ile tamamlanan bir süreçtir. Kesilme üreten
uyarılar, bilgisayar sisteminin yapısı içinde tür ve sayıca dondurulmuĢ
bulunduklarından, bunları iĢleyecek görevlerin sayısı da belirlidir. Kelimeleri yöneten
sistem, bu nedenle hangi görevi seçeceğini ve anahtarlayacağı göreve iliĢkin yapının ana
belleğin neresinde bulunduğunu kesin olarak bulabilir. Ancak, tüm görev ortamının
donanımca saklanıp, günlenmesi uzun zaman alan bir eylem olabilir. AĠB'deki bazı
yazmaçların ve kesilen göreve iliĢkin verilerin saklanmaları, kesilmeyi iĢleyecek göreve
bırakabilir.
4.2. Kesilme Türleri
Kesilmeleri, bilgisayar sisteminin iç veri yolu(ları) üzerinde bulunan birimlerden
kaynaklanan "iç uyarılara" ve çevre birimlerinden gelen "dıĢ uyarılara" bağlı olarak, iki
grupta toplayabiliriz.
Ana bellek, AĠB ve alt öğeleri, bu birimlerin besleme kaynakları vb. donanım,
sistemdeki temel aksamaları belirten uyarılar üretirler. Örneğin, AĠB'nin iĢlemekte
olduğu komutu öngörülen sürede sonuçlandıramaması, AĠB'nin tanımadığı bir komutla
karĢılaĢması, aritmatik mantık birimin hatalı bir sonuç bulması ya da iĢlenen türlerinin
uyuĢmaması, ana bellekteki eĢlik hataları, gerilimin düĢmesi vb. olaylar, sistem
bütünlüğünün korunabilmesi için öncelikle ele alınması gerekli iç uyarıları üretirler.
DıĢ uyarılar ise giriĢ/çıkıĢ donanımı, gerçek zaman saati, yardımca iĢlem
birimleri (örneğin kanal) vb. donanımdan kaynaklanırlar. Bu uyarıların zamanında
yanıtlanması, uygulanan programlar açısından önemli olmasına karĢın, iç uyarılar gibi,
sistemin tümü için yaĢamsal önem taĢımazlar. DıĢ uyarılar, bir aygıtın yapmakta olduğu
görevi bitirip serbest duruma geçmesi üzerine, ya da bu birimlerde oluĢan bir hatayı
AĠB'ne yansıtmak için üretilir.
IBM'in MVS ve VM altında çalıĢan main frame'leri için altı tip kesinti
(interrupt) vardır. Bunlar;
1) SVC (Supervisor Call Interrupts): ÇalıĢan bir süreç tarafından SVC komutu
iĢlenir. SVC, kullanıcı tarafından bir g/ç iĢlemini gerçekleĢtirmek, daha fazla bellek
sahası almak veya sistem operatörü ile iletiĢim kurmak gibi belirli bir amaç için
kullanılır. SVC mekanizması, iĢletim sisteminin kullanıcılara karĢı güvenliğini sağlar.
Kullanıcı keyfi olarak iĢletim sistemine giremez. Bu iĢlemi SVC aracılığı ile yapar.
2) G/Ç Kesintileri: Bu kesintiler g/ç donanımı tarafından baĢlatılır. Bu kesintilerle
AĠB'ne, birim veya kanal statülerinin değiĢtiği bildirilir. g/ç kesintileri, g/ç iĢlemi
tamamlanınca, bir hata ortaya çıkınca veya aygıt hazır olunca oluĢur.
3) External Kesintiler: Bu kesintilere birçok değiĢik olay neden olur. Bunların bazıları;
kesinti saati üzerinde Quantum'un sona ermesi (bir iĢe AĠB'nin belli bir süre atanması),
35
operatörün konsol kesinti tuĢuna basması, çok iĢleyicili sistemler (Multi-processor)
üzerinde bir iĢleyiciden sinyal alınmasıdır.
4) Restart Kesintiler: Bu tür kesintiler operatörün konsolun restart tuĢuna basmasıyla
veya çok iĢleyicili sistemler üzerinde diğer bir iĢleyiciden restart SIGP (signal
processor) komutunun gelmesiyle oluĢur.
5) Program Check Kesintiler: Sıfıra bölme iĢlemi, ayrıcalıklı bir komutun iĢletilmesi
veya geçersiz iĢlem kodunun oluĢması gibi nedenlerle ortaya çıkan kesintilerdir.
6) Machine Check Kesintiler: Donanım arızaları tarafından ortaya çıkan kesintilerdir.
4.3. Kesilmelerde Sıradüzen
Bilgisayar sisteminde yer alan birimlerin ürettikleri uyarılar, yansıttıkları
olayların önemine ve iĢletime alınmak için bekleyebilecekleri sürelere göre, farklı
öncelikler taĢırlar. Daha önce de değinildiği gibi, iç uyarılardan kaynaklanan kesilmeler,
dıĢ uyarılara bağlı olanlara göre, daha öncelikli sayılırlar. Örneğin satır yazıcıdan gelen
uyarıyı iĢlemek üzere, uygulanmakta olan programı kesen bir görevin, sistemde
gerilimin düĢtüğünü belirten uyarı karĢısında, AĠB'ni bu kesilmeyi iĢleyecek göreve
bırakılması gereklidir. En öncelikli kesilmeyi iĢleyen görev sonuçlandığında, iĢletim bu
görevin kestiği yerden sürdürülecek ve bu iĢlemin, kesilmeye uğrayan tüm görevler
sonuçlanana değin yinelenecektir.
Günümüz bilgisayar sistemlerinin tümü, kesilme iĢlemleri arasında sıradüzen
kuran, çok düzeyli ve karmaĢık kesilme sistemleriyle donatılmıĢlardır. Ancak, bir
bilgisayar sisteminde bulunan tüm birimlerin üretecekleri herbir uyarı için, ayrı bir
kesilme ve farklı bir öncelik tanımlamak, gereksinen donanım nedeniyle olanaksızdır.
Bilgisayar sistemlerindeki kesilmeleri ve öncelik düzeylerini kabul edilebilir sayıya
sınırlamak üzere, benzer uyarıların aynı kesilmeyi üretmeleri ve eĢöncelikli kesilmelerin
de, eĢ düzeyler oluĢturmaları öngörülmüĢtür.
Kesilmelerdeki sıradüzeninin donanımın yapısıyla dondurulmuĢ bulunması ve
kesilmeleri iĢleyecek görevlerin donanım donanımca anahtarlanmaları, programların
bütünlüğü yönünden sakıncalı sonuçlar yaratabilir. Bir iĢi, uyum içinde birlikte yürüten
görevler, çalıĢmalarının bazı aĢamalarında, zaman içinde bölünmesi sakıncalı, kritik
iĢlemler yaparlar. Örneğin, ortak kullanılan bir veri, bir kaynak, baĢka bir görevin
iĢletime girmesiyle, mantıksal ya da fiziksel nedenlerle kaybedilebilir. Yönelttiği iĢlev
ve bu iĢlevin önceliği ne olursa olsun, programlardaki kritik aĢamalarda gereksenen
tutarlılığı sağlamak üzere, yazılıma, kesilme sisteminin çalıĢmasini denetleyen ve bazı
kesilmeleri engelleyen olanaklar tanınır. Bunlardan, sistemin temel komutlarıyla
gerçekleĢtirilenleri, "MASKELEME" diye adlandırılır. Programlar, maskeleme yolu ile,
istemedikleri uyarıların kesilme üretmelerini engelleyip, AĠB'ni bu görevlere
kaptırmayabilirler. Ancak, sistemi uyarılara kapama süresinin çok sınırlı olması ve
paralel süren fiziksel oluĢumları bozmaması gereklidir.
36
4.4. Kesilmelerin ĠĢlenmesi
Bir bilgisayar sisteminde kesilmeler:
a) uyarıların kesilmeye dönüĢmesi,
b) görev anahtarlama,
c) iĢletim,
d) kesilen göreve dönüĢ adımlarını içeren, donanım ve yazılımdan oluĢan bir
mekanizma ile iĢlenirler (ġekil-13).
Görev anahtarlama ve geri dönüĢ iĢlemleri, kullanılan sistemin yapısına göre
değiĢen oranda, yazılım ve donanım desteği gerektirirler.
Donanım birimlerinin ürettikleri uyarılar, iĢlenene değin AĠB'nin bir
yazmacında, ya da kesilme isteminde bulunan birimde, özel bir iki durumda saklanırlar.
Bir sistemdeki uyarılar yalnız aĢağıdaki koĢullar sağlandığında kesilme
oluĢturulabilirler.
a) Uarının bağlı olduğu kesilme engellenmemiĢ ise,
b) Daha öncelikli bir düzey kesilme oluĢturmamıĢ ise,
c) Her iki koĢul sağlandığında, AĠB kesilebilir bir evrede ise.
AĠB, sistem komutlarını uygularken, iĢlenen komuta özgü yerel veriler
ürettiğinden, rastgele bir zamanda iĢlemini kesip, yeni bir göreve yöneltilemez.
ĠĢlenmekte olan komutun sonuçlanmasını izleyen algetir süreci, hemen her AĠB'nin
kesilmelere izin veren evrelerinden biridir. Ayrıca, iĢletimi çok uzun süre gerektiren
komutların, algetir evresi dıĢında da kesilmeleri zorunludur. Örneğin dolaylı adresleme
yapılan bir sistemde adres zincirinin uzaması, ana bellekte verileri kaydıran bir komutun
çok büyük bir alanı baĢka bir yere taĢıması, yazmaç kaydırma iĢlemleri, kesilmeler yolu
ile izlenmesi gereken olayların iĢlenmelerinde gecikmelere neden olabilirler. Bu tür
komutların, her iĢletim adımında (1 byte aktardıktan sonra, yazmaç 1 adım
kaydırıldıktan sonra vb.) kesilebilmeleri zorunludur. Ancak, iĢletimi yarıda bıraktığı bir
komutu, kaldığı yerden sürdürecek bir AĠB'nin de, daha karmaĢık yapıda olacağı açıktır.
37
Kesilmenin
Kabul
- Uyarının kesilmeye dönüşmesi
(Bundan sonra sistem tüm kesilmelere kapanır.)
Edilmesi
Görev
Anahtarlama
- Kesilmeyi işleyecek görevin anahtarlanması.
- Görev anahtarlama işleminin tamamlanması.
D
O
N
A
N
I
M
- Sistemin diğer bazı uyarılara açılması.
İşletim
Y
A
Z
I
L
I
M
- Uyarıyı üreten birimin gereksediği hizmetin üretimi
(Bu adımda uyarının bağlı olduğu kesilme düzeyi de serbest
bırakılabilir.)
- Kesilmelerden bir kesimin maskelenmesi.
- Kesilmeyi işleyen görevin çalışma ortamının saklanması.
Sonuçlanma
- Kesilen görevin çalışma ortamının kurulması.
- Kesilen göreve dönüş.
D
O
N
A
N
I
M
ġekil-13. Kesilmelerin ĠĢlenmesi.
Herhangi bir uyarı iĢletime alındığında, yazmaçlarda saklanan kesilme isteminin
kaldırılması gereklidir. Bu iĢlem ya uyarının kesilmeye dönüĢmesi sırasında, kesilme
sistemince, ya da iĢletim evresinde uygulanan programla yapılır. Ayrıca, bazı giriĢ/çıkıĢ
birimlerinin aynı nedene dayalı olarak kesilme üretmesini engellemek, bu birimi süren
yazılımın görevidir.
Kesilmenin sonuçlanma evresi, kesilen görevin çalıĢma ortamının yeniden
oluĢturulmasına iliĢkin iĢlemleri içerir. Bu iĢlemler süresince, kesilmiĢ olan görev
kimliği hakkında hemen hiçbir varsayım yapılamaz. Kesinlikle bilinen tek olgu,
kesilmeyi iĢleyen görevin, kendisinden daha öncelikli bir görevi kesmemiĢ olduğudur.
5. GiriĢ/ÇıkıĢ Donanımının Yönetimi
ĠĢletim sistemlerinde, çekirdeği oluĢturan katmanın yürüttüğü en karmaĢık görev,
hiç kuĢkusuz, giriĢ/çıkıĢ donanımının yönetimidir. Bilgisayar sistemine bağlanabilen
giriĢ/çıkıĢ birimlerinin farklı yapılarda olmaları, bu birimleri ana sisteme bağlarken
izlenen yolların çeĢitliliği, yönetim iĢlevini güçleĢtiren baĢlıca etmenlerdir.
38
ĠĢletim sistemindeki çekirdek yazılım katmanı, bir yandan ana bellek ile çevre
birimleri arasındaki fiziksel veri akıĢını yönetirken diğer yandan da, bu birimlerin
fiziksel faklılıklarını, daha üst düzeyde yer alan yazılıma yansıtmayan, tekdüze bir
eriĢim mekanizması sağlamakla yükümlüdür.
Bilgisayar çevre ile olan bağlantısını g/ç birimleri yoluyla sağlar. ĠĢlenecek
veriler ve kullanılacak programlar giriĢ birimlerinden AĠB'ne iletilir, iĢlem sonuçları bu
kez çıkıĢ birimleri aracılığıyla kullanıcıya geri beslenir. Burada iki yönlü iletiĢimin
gerçekleĢmesinde kullanılan aygıtlar G/Ç Birimleri olarak anılır.
5.1. Bağlantı Arabirimi
Tümüyle eloktronik olan ve çok hızlı çalıĢan AĠB'ne karĢın, g/ç birimlerinin
hepsi elektromekanik ve göreli olarak oldukça yavaĢtırlar. Ġkisi arasında kurulan
bağlantıda böylesi farklılıkları bağdaĢtırabilmek ve gerekli olacak diğer iĢlevleri
üstlenmek üzere bağlantı arabirimi kullanılır. ġekil-14'te bir g/ç biriminin böyle
bağlantısı görülüyor.
AİB
Bağlantı
G/Ç Birimi
Arabirimi
ġekil-14. Bağlantı Arabiriminin KullanılıĢı.
ġekil-14'teki iki yönlü oklar çok bitli bilgi yollarını göstermektedir. Bunlardan
AĠB ile bağlantı arabirimi arasındaki yol, AĠB'nin ana bilgi yolunun uzantısıymıĢçasına
algılanabilir. AĠB yazmaçlarından ya da doğrudan bellekten çıkıĢ birimine gönderilecek
veri bu yoldan iletilerek arabirime ulaĢır. Arabirim, bir yandan çıkıĢ biriminin özelliğine
göre uygun olacak düzenlemeleri yaparken, diğer yandan veriyi geçici olarak depolar.
Burada kullanılan bellek birimine veri yazacı (VY) denir. VY'de bekletilen veri, uygun
zamanlama sırası geldiğinde çıkıĢ birimine aktarılır. Eğer iletim g/ç biriminden (bu
örnekte, giriĢ birimi) AĠB'ne doğru olacaksa, giriĢ biriminin sağladığı veri VY'de
biriktirilir. Bu sırada kullanılan giriĢ biriminin özelliğine göre gerektireceği
düzenlemeler arabirimce yerine getirilir. VY'de derlenen veri daha sonra arabirimden
AĠB'ne iletilir. AnlaĢılacağı gibi g/ç sürecinde gereken yastıklama (tamponlama) iĢlevi
bağlantı arabirimi tarafından ve VY kullanılarak sağlanmaktadır; verinin iletimi AĠB'nin
anayolu uzantısınca sağlanan yol üzerinde olmaktadır. Bu yol, veri hatları olarak anılır.
Veri yazacı AĠB'den aldığı veriyi henüz çıktı birimine ulaĢtıramamıĢken, AĠB'nin
yeni veri göndermesinin bilgi kaybına yolaçacağı açıktır. Ters yönde iletimde de benzer
durum ortaya çıkabilir. Böylesi istenmeyen olayları önlemek amacıyla bağlantı
arabiriminde bir yazaç daha bulunur. Flag (bayrak) yazacı (BY) olarak anılan bu yazaç
VY'nin dolu olup olmadığını, baĢka bir deyiĢle içindeki verinin kullanılmıĢ olup
39
olmadığını belirler. Bir bitlik olan BY'nin değeri 1 iken VY'nin dolu (meĢgul) olduğunu,
0 (sıfır) iken VY'nin boĢ (serbest) olduğunu gösterir. Örneğin, bir çıkıĢ iĢleminde, AĠB
VY'yi doldurduğunda BY'yi 1 yapar, çıkıĢ birimi BY'nin 1'e dönüĢmesi üzerine VY'deki
verinin çıkıĢını yapar ve BY'yi 0'a dönüĢtürür. Bunun gibi bir giriĢ iĢleminde VY'ye yeni
veri aktaran giriĢ birimi BY'yi 1 yapar. BY'nin 1'e dönüĢtüğünü algılayan AĠB, yeni
veriyi VY'den alır ve BY'yi 0 yapar. Böylece BY kullanılarak, dolu VY'ye yeni veri
koyarak açılan veri kaybı ile boĢ VY'den dolu imiĢçesine veri alınarak yol açılan
yanlıĢların önü alınmıĢ olur.
VY ve BY en yalın bir bağlantı arabiriminin bileĢenleridir. VY'nin uzantısı nasıl
veri hattı varsa, BY'nin uzantısı da durum hattı olarak anılır. ġekil-15’te yalın bir
bağlantı arabiriminin bileĢenleri görülmektedir.
Durum Hattı
AĠB
Veri Hattı
VY
BY
G/Ç Birimi
ġekil-15. Yalın Bir Bağlantı Arabirimi
Bir AĠB'ne bağlı birden çok g/ç birimi olacağı açıktır. Tüm g/ç birimleri aynı
özelliklerde olmadığından, ve örneğin, bir giriĢ iĢleminin hangi giriĢ biriminden
gerçekleĢtirildiğinin bilinmesi gerekeceğinden tüm birimler ayrı ayrı adreslenebilir
olmalıdır. Diğer bir deyiĢle, bağlantı arabirimi, bağlı g/ç biriminin adresini de içermek
ve AĠB'den gelen iletileri ancak bu adrese ise kabul etmek durumundadır. Bu iĢlev için
bağlantı arabiriminde bir adres seçici devre bulunur. Bu devre, adres hattı adı verilen
uzantıdan girdilerini alır; eğer girdi adres, birimin adresi ise gerekli zamanlama ve
denetim düzenlemelerinin yerine getirilmesini sağlayan bir çıktı üretir. Adres hattı tıpkı
veri hattı gibi çok bitli ve paralel bir iletim ortamıdır.
Bir g/ç biriminin yerine getireceği oku, yaz, bayrak yazacını yaz/boz gibi iĢlevler
olacaktır. Bunlardan hangisinin seçildiği g/ç iĢlemi yapılırken belirtilir. Bu belirtilen
iĢlev hattı anılan hat yoluyla iletilir ve bağlantı arabirimi içindeki iĢlev çözücü
devrelerce algılanır. Devrelerin çıktısı, gerek fiziksel g/ç biriminin özdenetiminde,
40
gerekse bağlantı arabiriminin zamanlama ve denetim düzenlemelerinde kullanılır.
Bağlantı arabirimi kendi zamanlama ve denetim devrelerini de içerir.
Görülüyor ki bir g/ç aygıtı, bağlantı arabirimi aracılığıyla ve değiĢik amaçlar için
var olan hatlar yolu ile AĠB'ne bağlanıyor. Bu durum ġekil-16'da gösterilmektedir. G/Ç
hattı AĠB ile g/ç birimini bağlayan bir yoldur. Bir g/ç komutunun iĢletimi için gerekli
beslenmelerin uçtaki birime nerelerden verildiğini anlayabilmek için g/ç hattının AĠB
yanına da gözatmak gerekir. Veri hattının AĠB'nin anahattının uzantısı olduğu
belirtilmiĢti. Bu durumda veri hattı doğrudan doğruya birikeç, sonuç yazacı ya da bellek
veri yazacı gibi ana hatta açılan yazaçlar üzerindeki veri ile beslenebilir. Komut yazacı
geçerli g/ç komutunu içeriyor olacaktır. Bu durumda komutun iĢlev bölümü istenen
(oku, yaz gibi) g/ç iĢlevini, adres bölümü ise g/ç biriminin adresini taĢıyacaktır. Böylece
komut yazacının bunlara karĢılık gelen bölümleri iĢlev ve adres hatlarına
bağlanabilecektir. Durum hattı ise AĠB içinde yerleĢtirilen yeni bir yazaca doğrudan
beslenir. Durum yazacı adındaki bu yazaçtan g/ç programlanmasında çokça yararlanılır.
veri hattı
durum hattı
adres hattı
işlev hattı
AİB
durum
verisi
işlev
verisi
veri
BY
İşlev Çözücü
VY
Devre
adres
Adres Seçici
Devreler
Denetim ve
Zamanlama
Fiziksel
G/Ç
Aygıtı
ve
Denetimi
ġekil-16. Bağlantı Arabirimi ve G/Ç Hattı.
5.2. G/Ç Hattı
Veri, durum, adres ve iĢlev hatları topluca g/ç hattı adıyla anılır. Bağlantı
arabirimi de, g/ç aygıtı denetim birimi ya da kısaca denetim birimi olarak adlandırılır.
41
Örnektekinden daha geliĢkin bir g/ç hattı baĢka iĢlevsel althatlar da içerir. Böylece
değiĢik yapı ve iĢlevsellikteki g/ç birimleri uygun denetim birimi (DB) kullanılarak bir
ortak g/ç hattına bağlanabilir. ġekil-17'de böyle bir mikrobilgisayar kurgusu
(konfigürasyon) gösterilmiĢtir.
Bellek
G/Ç hattı
AİB
DB
Kart Okuyucu
DB
DB
Daktilo uç
Satır Yazıcısı
DB
Teyp
ġekil-17. Bir Mikrobilgisayar ve G/Ç Birimleri Kurgusu.
Ortaboy ve daha büyük bilgisayarlara, genellikle, çok sayıda ve güçlü g/ç
birimleri bağlanır. Bunların hepsi tek g/ç hattı üzerinde olursa hattı iletim gücü ve
verimle çalıĢılamayacağından birden çok ve nitelikleri farklı hatlar kullanılır. Burada her
g/ç hattı bir mini ya da mikrobilgisayarın anahattı uzantısı olup, kendisinden beklenen
iĢlev ve yeteneğe göre AĠB uygun biçimde programlanır. Bunlar özel amaçlı
bilgisayarlar olup "kanal" denilen adıyla anılırlar. Çoklayıcı kanal ve seçici kanal sık
rastlanan bir örnektir. ġekil-18'de bir büyük bilgisayar kurgusu görülmektedir.
42
Görüntülü
İşletmen ucu
Kanal 1
Kanal 3
AİB
Kanal 2 Ana Bellek
Disk
Sürücü
Kanal 4
Kanal 5
Mıknatıslı şerit
sürücüleri
Kart
Okuyucusu
Yerel Satır
Yazıcısı
Kart
Delici
Uzak Bağlantı
Yerel Bağlantı
Görüntülü İşletmen Ucu
Uzyazıcı
Uzyazıcısı
Görüntülü Uç
Görüntülü Uç
Uzak satır
Yazıcısı
Uzak satır yazıcısı
ġekil-18. Bir Büyük Boy Bilgisayar Kurgusu.
5.3. Kanallar
Kanallar, ana bellek ile giriĢ/çıkıĢ birimleri arasında, AĠB'nin doğrudan katkısı
olmadan veri aktarımı yapabilen, özel amaçlı yardımcı iĢlem birimleridir. Bilgisayar
sistemlerinde, g/ç iĢlemlerini destekleyen yardımcı birimlere olan gereksinim, mıknatıslı
teker, mıknatıslı Ģerit gibi yüksek hızda veri ileten çevre birimlerinden kaynaklanmıĢtır.
AĠB gibi pahalı bir birimin, bir g/ç iĢlemi süresince baĢka bir göreve yöneltilmesini, ya
da birçok giriĢ/çıkıĢın paralel sürdürülmemesi sistemin baĢarımını, verimliliğini büyük
ölçüde etkileyebilmektedir. Bilgisayar sistemlerinin görünümü büyüdükçe, çevre
birimlerinin iletiĢim hızları arttıkça, kanallar da bilgisayar sistemlerinin
vazgeçilemeyen, temel donanımı arasına katılmıĢlardır.
43
5.3.1 Kanalların ÇalıĢma Ġlkeleri
Kanallar, yapısal açıdan AĠB'lerine benzeyen, kontrol ünitesi, yerel bellek,
yazmaç vb. öğelerle donatılmıĢ iĢlem birimleridir. Toplama, karĢılaĢtırma gibi aritmetik
ve mantıksal iĢlemlerin yanısıra, AĠB ile g/ç yapabilecek komutları ve ana belleğe
doğrudan eriĢim yapabilecek olanakları içerirler.
Kanallar, yapılarına özgü komutlar ile programlanırlar. Daha çok parametrik bir
anlatıma benzeyen kanal programları; iletiĢim kurulacak çevre biriminin adını, yapılacak
giriĢ/çıkıĢın yönünü, verilerin ana bellekteki konumunu, sayfa baĢı, kütük atlama gibi
özel iĢlevleri, g/ç sonunda yapılması gereken eylemleri tanımlarlar.
AĠB, kanalı herhangi bir çevre birimi gibi görür ve kanal programını (ya da bu
programın ana bellekteki konumunu) g/ç komutlarını kullanarak bu birime aktarır.
Kanal çalıĢmaya baĢladıktan sonra, AĠB ile bağlantısını keser ve iĢlemlerini bağımsız
olarak sürdürür. Kesilme sistemi de, kanalın denetimindeki çevre biriminden
kaynaklanan uyarıları, AĠB yerine kanala yöneltir. G/Ç iĢlemi sonuçlandığında, kanal
AĠB'ni uyarır. AĠB bu aĢamadan sonra giriĢ/çıkıĢın nasıl sonuçlandığını inceleyen ve
gereken önlemleri alan yazılımı devreye sokar.
Kanallar, g/ç iĢlemlerini AĠB'den bağımsız yürütebilmelerine karĢın ana belleğe
ulaĢabilmek için AĠB ile zaman uyumu sağlamak zorundadır. Bellek yolunu
bölüĢebilmek için gereksinen altyapı, konumuz dıĢında yer aldığından
incelenmeyecektir.
5.3.2. Kanal Türleri
Bilgisayar sisteminde, hızlı iletiĢim yapabilen her birim için ayrı bir kanalın
kullanılması, pahası nedeniyle geçerli olmayan bir çözümdür. Ayrıca, bigisayar
sisteminin baĢarım/eder oranı da, kanal sayısına bağlı olarak doğrusal biçimde artmaz.
Bu nedenlerle, birçok çevre birimini tek bir kanal üzerinde toplayan yapı, yaygın olarak
benimsenen bir çözümdür.
Bir g/ç iĢlemi için, kendisine bağlı çevre birimlerinden yalnız birini seçip, iĢlem
sonuçlanana değin bu bağlantıyı kesmeyen kanal türünü, Seçici Kanal (Selector
Channel) diye adlandırıyoruz. Seçici Kanal bir birim ile giriĢ/çıkıĢı sürdürürken, ona
bağlı öteki birimlere ulaĢım olanağı vermez.
Kanalları ana belleğe bağlayan eriĢim yolu, veri iletiĢim sığası çok yüksek olan
bir donanımdır. ĠĢlem hızı genellikle ana belleğin eriĢim süresi ile sınırlanan eriĢim
yolunu, bütün bir g/ç iĢlemi süresince tek bir birimin g/ç iĢlemine atamak, bu donanımın
iletiĢim sığasını çevre biriminkine indirgemek demektir.
Kart okuyucu, satır yazıcı gibi yavaĢ sayılan birimler, bu değinilen sakıncayı
kaldırmak üzere, BölüĢümlü Kanallar (Multiplexed Channels) üzerinde toplanırlar. Bu
kanal türü birçok çevre birimi ile paralel g/ç yapabilecek yapıdadır. Herhangi bir birim
için ana bellek eriĢimi gerektiğinde, bölüĢümlü kanal, bellek yolunu ilgili birime
44
anahtarlar. Çevre birimlerini paralel çalıĢtırabilen ve bellek yolunu daha yoğun
kullanabilen bu yaklaĢım, bilgisayar sisteminin daha verimle kullanılmasını olanaklı
kılar.
Seçici kanal dıĢında, yüksek hızda veri ileten birimlerini ÖbeklenmiĢ BölüĢümlü
Kanallar (Block Multiplexed Channels) üzerinde toplanmaları öngörülmüĢtür. Bu tür
kanallar, kendinden hizmet bekleyen birimlerin programlarını, zaman bölüĢümü yaparak
iĢlerler. BaĢka bir deyiĢle, her kanal programı blok blok uygulanarak, birimlerin paralel
çalıĢtırılma olasılığı yükseltilir. ġekil-19 her üç kanal türünü ve bağlanabilecek çevre
birimlerini göstermektedir.
Bellek Yolu
Ana Bellek
Seçici Kanal
Bölüşümlü
Kanal
Öbeklenmiş
Böl. Kanal
ġekil-19. Kanal Türleri 1.
Çok yüksek hızda iletiĢim yapan birimleri, sadece seçici kanalları kullanarak sisteme
bağlamak, verimliliği tartıĢılır bir çözümdür. Paralel çalıĢmaları istenen birimlerin aynı
kanal üzerinde olmaları, kaçınılmaz olarak beklemelere yol açar. ġekil-20a, bir
sistemdeki üç kanaldan ikisinin boĢ olarak beklediği, aynı kanal üzerindeki 1, 2 ve 3
nolu birimlere yöneltilen g/ç istemlerinin ise, sıradan istendiği bir yapıyı göstermektedir.
Bu sakıncalı durum, kanalları ve çevre birimlerini g/ç sırasında dinamik olarak
iĢleyen, Kayar Bağlantılı Kanalların (Flisating Channels) kullanılmasıyla giderilir
(ġekil- 20b). Bu yaklaĢımda bir g/ç önce boĢ bir kanalın seçilmesi, sonra da kanal çevre
birimi ile iliĢkisinin kurulmasıyla baĢlar. Kanalların tümü dolu olduğunda, yeni bir g/ç
isteminin bekletilmesi kaçınılmazdır. Ancak bu bekleyiĢ, herhangi bir kanalın serbest
kalmasına kadar sürer.
45
Bekleyen giriş/çıkışlar
2
1
1
3
Kanal 1
Seçilen Birim
G/Ç
Bekleme
Kuyrukları
Kanal 2
2
3
4
5
boş
Kanal 3
6
a) Seçici Kanalların Kullanıldığı Çözüm
1
1
Kanal 1
2
Giriş/Çıkış
Bekleme
Kuyrukları
3
2
Yol Eşleme
Donanımı
Kanal 2
3
Kanal 3
4
5
6
b) Kayar Bağlantılı Kanal Çözümü
ġekil-20. Kanal Türleri 2
46
g/ç
yapan
birimler
5.4. GiriĢ/ÇıkıĢların Programlanması
Bilgisayar sistemine aygıt denetici ve bölüĢülen bir g/ç ortamı aracılığı ile
bağlanan çevre birimlerinin yönetimi, kalıplaĢmıĢ sayılabilecek bir dizi iĢlemi içerir. Bir
çevre birimi ile iletiĢim kurabilmek için;
a) gerçekleĢtirilecek iĢlemi tanımlayan, gerekiyorsa çevre biriminde fiziksel
düzenlemeler yapan yönetim komutunu, çevre birimini süren aygıt deneticiye iletmek,
b) aygıt denetici/çevre biriminin ne durumda olduğunu saptamak ve yönetim
komutunun alınıp alınmadığını denetlemek üzere, aygıt deneticinin durum belirteçlerini
sınamak,
c) gerekiyorsa, ilk adımda verilmiĢ olan yönetim komutunun gerçekleĢmesini
beklemek ve oluĢabilecek aksamaları yakalamak,
d) giriĢ ya da baĢlatacak komutu aygıt deneticiye iletmek,
e) iletiĢimin sonuçlanmasını beklemek,
f) aygıt deneticinin belirteçlerini sınayarak, iĢlemin sağlıklı gerçekleĢip
gerçekleĢmediğini denetlemek, oluĢan bir aksamada gereken önlemleri almak,
g) aktarılacak veri kaldı ise, aygıt deneticinin özelliğine göre yeniden (d) ya da
(e) adımına dönmek, gerekmektedir. Bu iĢlemler, AĠB'nce doğrudan yapabilecekleri
gibi, kanallar aracılığıyla da dolaylı olarak yürütülebilirler.
Yukarıda sıraladığımız iĢlem dizisindeki iki adım (c) ve (e), yazılım ve donanım
arasında zaman uyumunun sağlanmasını gerektirmektedir. AĠB'nin doğrudan yürüttüğü
giriĢ/çıkıĢlarda bu sorun, belli baĢlı iki yöntemle çözülmektedir: a) aygıt deneticinin
durum belirteçlerini kullanarak, b) kesilme sistemini kullanarak.
5.4.1. Durum Belirteçlerinin Kullanılması
Bir aygıt deneticiye/çevre birimine verilen görevin sonuçlanmasını beklemenin
en iyi yolu, aygıt deneticinin durum belirteçlerindeki değiĢimi izlemektedir. Bu
yaklaĢım, beklenen bit görünümünü aygıt deneticinin durum belirteçlerinde oluĢana
kadar, programı bir döngü içinde tutmaya dayanır. Yöntem, AĠB'nin iĢlem hızını,
belirteçleri sınanan g/ç biriminin hızına indirgediği ve paralel iĢlem olanağını kaldırdığı
için verimsizdir. Ancak, çok az komut ve veri ile gerçekleĢtirilebildiğinden, bazı
durumlar için geçerli çözümü oluĢturabilir. Özellikle sistem yazılımını ana belleğe ilk
kez yüklerken, zorunlu olarak kullanılanılır. Durum belirteçlerini sınayarak yürütülen
giriĢ/çıkıĢlarda, aygıt deneticinin, bir hatayı ya da serbest kaldığını belirtmek için,
kesilme üretmemesi gereklidir. Bu kesilmeler ya AĠB'nde ilgili uyarı düzeyini ya da
aygıt deneticideki iki durumluları maskeleyerek engellenebilir.
5.4.2. Kesilme Sisteminin Kullanılması
Durum belrteçlerini kullanarak yürütülen giriĢ/çıkıĢlarda, AĠB'nin döngüsel
beklemeler içinde yitirdiği süreler, özellikle karakter tabanında iletiĢim yapan birimlerde
büyük boyutlara varır. Örneğin, saniyede 30 karakter yazabilen bir çıkıĢ biriminde, her
karakter için ~33 ms tüketilecektir. Bu süreleri, baĢka bir iĢlevi gerçekleĢtirmek üzere
değerlendirme kaygısı, çok iĢ düzeninde çalıĢan sistemlerin çıkmalarına yol açmıĢtır.
47
Durum belirteçlerini kullanarak yapılan giriĢ/çıkıĢlara göre daha karmaĢık
programlama gerektiren bu yöntem, çevre biriminin yanısıra, kesilme sistemine de
egemen olmayı zorunlu kılar.
6. Donanımda Öngörülmeyen Komutların ĠĢletimi
Günümüzde birçok bilgisayar sistemi, AĠB'nin komut kümesi içinde bulunmayan
bazı komutları, donanımın temel öğeleri arasında yer alıyormuĢ gibi, kullanıcıların
hizmetime sunmaktadır. Uygulamalarda az kullanılan özel amaçlı komutlar için,
donanım üretilmesini gerektirmeyen her yaklaĢım, gerçekleĢtirilebilmeleri karmaĢık özel
iĢlevleri iĢletim sistemine yükleyerek bunların, tutarlı ve güvenilir biçimde
yürütülmelerini sağlar.
Yapımcı firmalar, geçtiğimiz yirmi yılda, AĠB'nin yüksek ederini düĢürebilmek
için, kayar noktalı ve çift duyarlı aritmetik, liste iĢleme gibi iĢlemlere yönelik bazı
komutlara iliĢkin donanımı, AĠB'nin temel görünümünden ayırıp, ek olarak
pazarlamıĢlardır. Ancak, donanımda öngörülmeyen komutların gerek sistem yazılımını,
gerekse uygulama programlarını etkilememeleri için de, iĢletim sistemlerini, eksik
komutların iĢlevlerini görebilecek biçimde düzenlemiĢlerdir. Günümüzde donanımın
ucuzlaması, AĠB'lerini alt birimlere ayırmadan, uygun ederlerle, pazarlamayı olanaklı
kılmıĢsa da, bu yöntem, özel durumlar için henüz geçerliliğini sürdürmektedir.
48
BÖLÜM 3
VERĠLERĠN YÖNETĠMĠ
7.Veri Yönetimi Sisteminin BirleĢenleri
Günümüzde kullanılan programlama dilleri, ana belleğin dıĢında bulunan
verilerin, kütük diye anılan ortamlarda saklandıkları/üretildiklerini varsayar. Özellikle
üst düzeyli programlama dilleri, kullanıcılara, gerçek sistemin temel öğeleri arasında
bulunmayan karmaĢık veri türlerini ve bunlara iliĢkin iĢlemleri sunarak, sistemi gerçek
donanımdan soyutlar. Kütük kavramı da, sistemdeki giriĢ/çıkıĢ donanımının bir
soyutlamasıdır.
Her programlama dili, ana bellek ile kütükler arasında veri aktarımını sağlayan
okuma/yazma komutlarıyla donatılmıĢtır. Bu özel komutlarda geçen kütük tanımları,
esneklik ve taĢınırlık gibi nedenlerle, uygulamada kullanılan çevre birimlerinin gerçek
kimlikleri ve fiziksel özelliklerinden olduğunca bağımsız öğeler üzerinde kuruludur.
(Esneklik, bir programın yeniden düzenleme gerektirmeden değiĢik çevre birimleri ile
kullanılması; taĢınırlık ise, programın değiĢik sistemlerde uygulanabilme özelliğidir).
Bu nedenle, iĢletim sisteminin denetiminde çalıĢacak bir programın herhangi bir çevre
biriminden veri giriĢ/çıkıĢı yapabilmesi için önce, programın simgesel evreninde bir
kütük tanımı ile, sistem görünümünde giriĢ/çıkıĢ iĢlemi için seçilen birimin eĢlenmesi
gerekmektedir. BaĢka bir deyiĢle, giriĢ/çıkıĢ iĢlemini yürütecek kaynak(lar) bu
kullanıcıya atanacak ve program içindeki mantıksal birim ile, sistemdeki fiziksel birim
iliĢkilendirilecektir. Kaynakları yöneten sistem ile iĢbirliği yaparak bu iĢlevi
gerçekleĢtiren yazılımı, KÜTÜK YÖNETĠM SĠSTEMĠ diye adlandırıyoruz.
Mantıksal birim, fiziksel birim iliĢkisi kurulduktan sonra, uygulamaya alınan bir
programın giriĢ/çıkıĢ istemleri, GiriĢ ÇıkıĢ Yönetim Sistemi diye anılan katmanda,
mantıksal tutarlılık ve seçilen çevre birimi ile fiziksel uyuĢum denetiminden geçerek,
çekirdek sistem içinde, bu çevre birimini süren yordama yönetilirler. ġekil-21, Veri
Yönetim Sistemini ve iliĢkide bulunduğu öteki yazılım kesimlerini göstermektedir.
49
Kullanıcı
Kaynakların
Yönetimi
Kullanıcı
Kütük Yön. Sist.
Giriş/Çıkış
Yönetim
Verilerin
Yönetimi
Sistemi
.......
Kesilmelerin
Yönetimi
sürücü
yordam
1
sürücü
yordam
2
......
......
n
Çekirdek
Sistem
ġekil-21. Verilerin Yönetimi ve ĠliĢkili Yazılım.
7.1. GiriĢ ÇıkıĢ Yönetim Sistemi
GiriĢ ÇıkıĢ Yönetim Sistemi, ġekil-21'de kolaylıkla izleneceği gibi, çekirdek
sistemin sağladığı veri aktarım iĢlevi ile, daha üst katmanların giriĢ/çıkıĢ istemlerini
iliĢkilendiren, arabirim iĢlevini yürütür. Bu yazılım, çevre birimlerini süren yapının
kullanıcılara yansımasını engelleyerek, tüm birimler için ortak bir eriĢim mekanizması
kurar. Sistemde daha üst düzeyde yer alan programların giriĢ/çıkıĢ kesimleri, bu
katmanın iĢlevi nedeni ile, herhangi bir çevre birimine, ya da bu birimlerin fiziksel
özelliklerine bağımlı olmaktan kurtulurlar.
GiriĢ ÇıkıĢ Yönetim Sistemi'nin baĢlıca üç görevi bulunmaktadır;
a)giriĢ/çıkıĢ iĢleminin baĢlatılması
b)giriĢ/çıkıĢ isteyen program ile, fiziksel iĢlem arasında zaman uyumunun
sağlanması
c)giriĢ/çıkıĢ iĢleminin sonuçlandırılması.
50
GiriĢ ÇıkıĢ Yönetim Sistemi’ne yöneltilen istemler, içerik ve tutarlılık
denetimden geçtikten sonra, ilgili sürücü yordama yöneltilirler. GiriĢ/çıkıĢı yapacak
çevre birimine eriĢim yolunun seçilmesi ve gereksenen kaynakların bu iĢlem için
atanması, baĢlatma diye andığımız ilk aĢamada gerçekleĢtirilir. Çevre birimini süren
görev iĢletime baĢlatıldıktan sonra, giriĢ/çıkıĢ istemini yapan programın, iĢletimini
sürdürmesi, ya da giriĢ/çıkıĢ sonuna kadar beklemesi gerekmektedir. GÇYS bu iĢlevi,
görev yönetici ile iĢbirliği kurarak gerçekleĢtirir. Sistem çok görevli bir iĢletim türünde
çalıĢıyorsa, giriĢ/çıkıĢ iĢlemi süresince, AĠB baĢka bir göreve atanır.
GiriĢ/çıkıĢ iĢlemi sonunda, çevre birimini süren yazılım tarafından uyarılan
GÇYS, iĢlemin nasıl sonuçlandığı, ilgili kullanıcıya aktarır. Eğer kullanıcı, g/ç sonunu
beklemek üzere durdurulmuĢsa, GÇYS görev yöneticiyi uyararak kullanıcıyı, AĠB'ni
bekleyen hazır görevler arasına katar. Kullanıcı AĠB'ne kavuĢtuğunda, iĢletim
giriĢ/çıkıĢı izleyen komuttan sürer.
7.2. Kütük Yönetim Sistemi
Kütük Yönetim Sistemi, daha üst düzeydeki yazılım katmanlarının simgesel
evrelerinde tanımlanan kütükler ile sistemdeki fiziksel g/ç birimleri arasındaki eĢlemeyi
yapan, bu birimlerin etkin ve verimli biçimde kullanılmalarını sağlayan iĢlevlerin
toplandığı kesimdir.
Programlama dillerinde yer alan kütük tanımları kullanıcılara, gerek yapı gerekse
adlandırma yönlerinden gerçek sistemden olduğunca bağımsız kütükler kurma olanağını
sağlarlar. Örneğin üst düzeyli bir programlama dilinde, sıradan eriĢimli bir kütük, ard
arda kesintisiz olarak gelen tutanaklardan oluĢan bir yapıdır. Oysa bu kütük, bir
mıknatıslı teker üzerinde sektör, iz, silindir gibi fiziksel kalıplara bölünecek, belkide ard
arda gelmeyen konumlara yazılacaktır. Bu yapıyı kullanıcıya, programlama dili
düzeyinde algıladığı gibi yansıtmak, KYS'nin birincil iĢlevidir. Böylece bir kütük için
gereksenen alanların atanması, atamaların mıknatıslı tekerin en fazla veri saklayabilecek
ve giriĢ/çıkıĢlarda baĢarımı arttıracak biçimde yapılmaları, bu katmanın, çevre
birimlerinin etkin kullanımı için üstlendiği iĢlevlerden birkaçıdır.
KYS'nin çözmesi gereken sorunlardan en karmaĢık olanı, sistemdeki kütüklerin,
kullanıcılar tarafından adlandırılmasıdır. Her kullanıcı veri ve program kütüklerini,
kendine özgü simgelerle öteki kullanıcılardan etkilenmeyecek biçimde adlandırmak
ister. Böyle bir yapıda, ayrı kullanıcıların değiĢik kütükleri aynı ad altında
tanımlamaları, ya da aynı öğeye değiĢik adlar vermeleri kaçınılmazdır. Kullanıcıya özgü
bir simgeden yola çıkarak, sistemdeki bir g/ç birimine ulaĢmak ya da bir kütüğün çevre
birimi üzerindeki konumunu bulmak ve bu iĢlemler sırasında sistemde paralel çalıĢan
öteki kullanıcılarla oluĢabilecek uyuĢmazlıkları çözmek, KYS'nin bu yöndeki iĢlevlerine
örnek olarak verilebilir.
51
8. Kütük Yönetim Sisteminin ĠĢlevsel Kesimleri
KYS'ni, sıradüzensel bir yapı içinde, dört iĢlevsel katmana ayırabiliriz;
a) mantıksal düzey
b) temel düzey
c) fiziksel düzenleme kesimi
d) stratejik yönetim kesimi (ġekil-22).
Sistemdeki herhangi bir kütük bu düzeylerde, sırası ile ad, kimlik ve tanımlayıcı veriler
ile gösterilir ve kullanılır.
Kullanıcı
Kullanıcı
1
K
Ü
T
Ü
K
Y
Ö
N
E
T
İ
M
SİSTEMİ
Kullanıcı
2
3
kütük
adı
Mantıksal Düzey
kütük
kimliği
Temel Düzey
Fiziksel
Düzenleme
K1
Fiziksel
Düzenleme
Fiziksel
Düzenleme
K2
Ç.B
Stratejik
Yönetimi
K3
Ç.B
Stratejik
Yönetimi
kütük
tanımlayıcı
GİRİŞ / ÇIKIŞ YÖNETİM SİSTEMİ
ġekil-22. Kütük Yönetim Sisteminin ĠĢlevsel Kesimleri
Kütük adı, kullanıcılar tarafından rasgele seçilen ve kütüğü kullanıcının bireysel
evreni içinde ötekilerden ayıran bir simgedir. Günlük yaĢamımızda kiĢilerin adları,
benzer amaçla kullanılan simgelerdir. Bir aile içindeki birey adları, kiĢileri
biribirlerinden ayırabilen niteliklerini yitirirler.
52
Kütük kimliği (file identifier), kütüğü bir sistem içinde ötekilerden ayıran
simgedir. Örneğin, kurumlardaki sicil numaraları, öğrenci numaraları, bu nitelikte
biricik tanımlardır.
Kütük tanımlayıcı (file descriptor) ise, kütüğe iliĢkin fiziksel ve mantıksal
özelliklerin tutulduğu veri kümesidir. Kütüklere fiziksel olarak ulaĢabilmek için, burada
bulunan bilgilerden yararlanılır. Günlük yaĢamımızda adres, iĢ yeri, doğum tarihi vb.
bilgileri içeren kimlik kartları, iĢlev açısından kütük tanımlayıcılara benzetilebilir.
8.1. Mantıksal Düzey
KYS'nde kütük adlarını, kimliklere dönüĢtüren iĢlevlerin toplandığı kesimi,
mantıksal düzey olarak adlandırıyoruz. Kullanıcıların simgesel evrelerinde tanımlamıĢ
kütük adları, ġekil-22'de gösterildiği gibi bu düzeyin altında anlamlarını yitirirler.
Mantıksal düzeydeki iĢlevler, kütük adı-kütük kimliği iliĢkisini kurabilmek için,
"Kılavuz" diye anılan veri kümelerini kullanırlar. Bir sistemde görünümü oluĢturan
çevre birimlerinin adlarını içerecek kılavuzun, kullanım sıklığı, sınırlı boyu, durgun
yapısı v.b. nedenlerle, ana bellekte, iĢletim sistemiyle birlikte bulunması doğaldır.
Ancak, mıknatıslı ortamlarda yaratılan kütükler için, bu yapının, gereksenecek yer ve
güvenirlik nedenleriyle, ana bellekte sürekli tutulması sakıncalıdır. Bir çok sistemde, bu
tür kılavuzların ikincil belleklerde saklanmaları ve öteki kütükler gibi kullanılmaları
öngörülmüĢtür.
Konumuzun bundan sonraki bölümlerinde, mıknatıslı ortamlarda yaratılan
kütükler için kullanılan kılavuz yapılarını inceleyeceğiz. Öteki kütük türleri için de
geçerli olan bu yapılar, sistem genelinde bulunan adlandırma sorununa çözüm getirmek
üzere de kullanılır.
8.1.1. Tek Düzeyli Kılavuz Yapısı
Kütük sayısının sınırlı, kullanıcıların kütük adlarını izleyecek kadar sisteme
yakın bulundukları çalıĢma düzenlerinde, kılavuzların, kütük adlarının tümünü, fiziksel
ve mantıksal özellikleriyle birlikte tutacak biçimde oluĢturulmaları, yalın ve yeterli bir
çözümdür.
Bu yapıyı incelemek üzere, mıknatıslı teker üzerinde bulunan kütüklerin
bilgilerini tutan bir kılavuzun, ġekil-23'te gösterilen verileri içerdiğini varsayalım. Ġki
boyutlu bir tablo gibi kullanacağımız bu yapıda her kütük, bir satır içinde yer alan
verilerle tanımlanmaktadır. Bir kütüğe iliĢkin verilerin bulunduğu satırın numarası ise,
kütüğün mıknatıslı teker düzeyindeki kimliğini oluĢturmaktadır. Bu mıknatıslı teker
üzerinde yaratılacak her yeni kütük için, önce, kılavuzda kullanılmayan bir kimlik
bulmak gerekmektedir. Kütüğü tanımlayan öteki veriler, daha sonra kılavuzdaki
yerlerine yazılacaklardır. Kütüğün silinmesi ise, kılavuzda kullanılan satırın "boĢ"olarak
nitelendirilmesine ve kullanımda olan alanların serbest bırakılmalarına indirgenmiĢtir.
53
Kütük Kütük
Kimliği Adı
1
A
2
X
3
4
T
Boş Tutanak Başlangıç Bitiş
Uzunluğu Adresleri
108
xxx
yyy
80
zzz
...
Tutanak
Sayısı
17
895
Erişim
Hakları
Oku / Yaz
İşletim
*
...
80
...
...
...
...
...
4050
...
Salt Oku
........
ġekil-23. Tek Düzeyli Kılavuz Yapısı 1.
ĠĢlediğimiz örnek yapıda kütük adı, kütük kimliği ve kütüğü tanımlayan veriler
arasında bağımlı, birebir iliĢkiler kurulmuĢtur. Bunun sonucunda;
a) aynı simge, değiĢik kütükleri adlandırmada kullanılmamakta,
b) bir kütüğe, ayrı ad ve eriĢim hakları vermek olanaksızlaĢmaktadır.
ġekil-23’te oluĢturduğumuz sağladığı iki iĢlevi; kütük adı, kütük kimliği, iliĢkisinin
kurulmasını ve kütüğü tanımlayan verilere eriĢimi ayrıĢtıran bir yapıya yöneldiğimizde,
yukarıda sıraladığımız sakıncalar da düĢecektir. Bu yeni yapıda, her kullanıcı için kütük
adı ve kütük kimliği iliĢkisini kuran, ayrı bir "Simgesel Kılavuz" bulunmaktadır (ġekil24). Kullanıcının kütük üzerindeki haklarını da içeren bu kılavuzlar, kütükleri
adlandırmada oluĢabilecek çakıĢma ve çeliĢkileri ortadan kaldırırlar. Mıknatıslı tekerin
üzerindeki kütükleri tanımlayan veriler ise, "Temel Kılavuz" diye adlandırdığımız,
tekere özgü, biricik kılavuzda saklanırlar.
Simgesel ve temel kılavuzların ayrıĢtırıldıkları yapılarda bir kütüğe eriĢebilmek
için, önce simgesel kılavuz taranarak kütüğün kimliği bulunur. Sonra, kütüğün yer aldığı
mıknatıslı tekere iliĢkin temel kılavuza eriĢilir ve bu kütükteki bilgiler, kütük kimliği
kullanılarak elde edilir Temel kılavuzun içinde, kullanıcı sayısını içeren alan, ilgili
kütüğün kaç simgesel kılavuzda yer aldığı göstermektedir. Silinen bir kütüğün, yok
edilebilmesi için, bu sayının sıfıra düĢmesi gereklidir.
54
Kütük Kütük Erişim
Adı
Kimliği Hakları
Kütük Kütük Erişim
Adı
Kimliği Hakları
A
1
Oku / Yaz
A
3
İşletim
T
4
İşletim
B
1
Salt Oku
X
2
Salt Oku
T
2
İşletim
Z
4
İşletim
1.Kullanıcı
2.Kullanıcı
a) Simgesel Kılavuzlar
Kütük
Kimliği
1
2
3
4
5
Kullanıcı
Sayısı
2
2
1
2
0
......
Tutanak
Uzunluğu
80
108
108
108
......
......
Başlangıç
Bitiş
Adresleri
xxx
yyy
zzz
......
......
......
......
......
......
......
......
......
Tutanak
Sayısı
320
10
48
......
......
......
b) Temel Kılavuz
ġekil-24. Tek Düzeyli Kılavuz Yapısı 2.
8.1.2. Çok Düzeyli Kılavuz Yapısı
Çok düzeyli kılavuz yapısı kullanıcılara, gerektiğinde biribirleriyle
iliĢkilendirilebilen, bir çok simgesel evren kurma olanağını sağlar. Böylece her
kullanıcı, mantıksal açıdan bir bütün oluĢturan kütüklerini ötekilerden ayrı, tek bir
kılavuz içinde toplanabilir. Ayrıca, daha önce değindiğimiz, simgesel kılavuzların
araĢtırılmasından kaynaklanan kolaylıklardan da yararlanır.
Çoğu sistemde, simgesel evrenler arasındaki iliĢki, sıradüzensel niteliktedir,
iĢletimde çıkabilecek sorunlar nedeniyle ağ yapısına benzer uygulamalardan kaçınılır.
ġekil-25'te iki düzeyli bir simgesel kılavuz yapısı verilmiĢtir. Kullanıcının ilk düzey
kılavuzunda A, X ve T kütüklerinin yanısıra, K diye adlandırılmıĢ ikinci bir kılavuz
bulumaktadır. Bu örnekte 4 kimlikli kütüğe eriĢim, 1.düzey kılavuzdan T simgesi ile
iĢletim için 2. düzey kılavuzdan ise, A simgesi ile okuma ve yazma yapmak üzere
sağlanmaktadır.
55
Çok düzeyli kılavuzların bulunduğu sistemlerde, kütük adını karĢılayan kimliği
bulabilmek üzere, bir baĢlangıç kılavuzunun belirlenmesi ve kütük adları zincirinden
oluĢan bir eriĢim yolunun tanımlanması gerekmektedir. ġekil-25'teki örnekte, 4 kimlikli
kütük 1.düzey simgesel kılavuzdan baĢlayarak T, ya da K/T biçiminde adlandırabilir.
Düzey
sayısının
ikiden
fazla
olduğu
durumlarda,
bu
sözdizimi
"Kılavuz1/Kılavuz2/.../Kılavuz n/Kütük Adı" biçiminde genelleĢtirilir.
1.Düzey Simgesel Kılavuz
A
1
İşletim
X
2
Oku / Yaz
T
4
İşletim
K
3
Salt Oku
Kütükler
2
1
4
5
2.Düzey Simgesel Kılavuz
C
5
A
4
6
Oku / Yaz
3
2.Düzey
Kılavuz
Kütük
ġekil-25. Çok Düzeyli Kılavuz Yapısı.
8.2. Temel Düzey
Temel düzey, mantıksal düzeyde kimliği belirlenen kütükler için, g/ç
iĢlemlerinde kullanılan kütük tanımlayıcıyı kurmakla yükümlüdür. Kütük açma iĢlemi
sırasında yaratılan bir veri kümesi olan, kütük tanımlayıcı: a)g/ç hizmetini isteyen
programda geçen kütük tanımı, b)bu programı sisteme sunan iĢ denetim dilindeki g/ç
iĢlemlerine iliĢkin öğeler, c)temel kılavuzdaki mantıksal ve fiziksel özellikler, d)sistem
iĢletmeninden alınan bilgiler ile kurulur.
Üst düzeyli programlama dillerinde geçen kütük tanımları, derleme aĢamasında,
sözdizimi ve mantıksal tutarlılık denetiminden geçerek, amaç program içinde iĢletim
sistemince bulunabilecek özel veri yapılarına dönüĢtürürler. ĠĢletim için sisteme sunulan
bir programın gereksediği g/ç donanımı, bu veri kümeleri taranarak saptanır. Hemen her
sistemin iĢ denetim dili, programlarda geçen kütük tanımlarını günleyen, gerektiğinde
56
tümüyle değiĢtiren deyimler içerir. Programın, iĢletim için gereksediği kaynaklar,
iĢletim baĢlamadan tümüyle ya da iĢletimde, istek üzerine teker teker atanırlar. ĠĢletim
aĢamasında, doğrudan ya da dolaylı uygulama kütük açma komutları KYS'nde, önce
mantıksal düzeyde, sonra temel düzeyde ele alınırlar. EriĢilmek istenen kütüğün
özelliklerini tutan temel kılavuz, programda geçen kütük tanımını sınamak ve günlemek
üzere baĢvurulan ana kaynaktır. Kütük tanımlayıcı oluĢtururken programda geçen
bilgiler ile, temel kılavuzdakiler arasında uyuĢmazlık saptanırsa, büyük çeliĢkiler
olmadığı sürece, temel kılavuzun verileri geçerli sayılır. Öteki durumlarda sistemde
benimsenen yaklaĢıma göre, iĢletim kesilir ya da sorunun çözümü sistem iĢletmenine
bırakılır.
Bir sistemdeki KYS'nin güvenilir ve etkin bir hizmet verebilmesi için,
sistemdeki kütüklerin fiziksel özelliklerini içeren temel kılavuzların, bazı ölçütlere göre
oluĢturulmaları zorunludur. Bunların en önemlilerini Ģöyle sıralayabiliriz;
a) Sistemdeki her kütük, birçok simgesel kılavuzda anılabilir olmasına karĢın,
fiziksel özellikler yönünden, yalnız bir temel kılavuzun içinde tanımlanmalıdr.
Bunun dıĢındaki bir uygulama, kütük için geçerli olan tanımı saptamada, çözümsüz
sorunlar yaratır.
b) ĠĢletim kolaylığı açısından, sökülür/takılır nitelikteki mıknatıslı birimlerde yer
alan kütükleri tanımlayan temel kılavuzun, bu kütükler ile aynı fiziksel ortamda
bulunmaları ile aynı fiziksel ortamda bulunmaları gereklidir. BaĢka bir yaklaĢım,
iĢletim hızını düĢüren sökme/takma iĢlemleri gerektireceği gibi, sürücü birimlerin
sınırlı olması nedeniyle, sistem düzeyinde kilitlenmelere de yol açabilir. Örneğin
tek sürücülü bir sistemde, mıknatıslı tekerdeki bir kütüğe eriĢebilmek için, önce
sürücüye temel kılavuzu içeren tekerin takılması, bunun kütüğü içeren tekerle
değiĢtirilmesi ve program sonuçlandığında, kütüğün son durumunu iĢlemek üzere,
temel kılavuzu taĢıyan tekerin yeniden takılması gerekecektir.
c) Temel düzeyin, daha alt kesimlerde yer alan iĢlevlerden yararlanabilmesi için,
temel kılavuzların, öteki ile eĢ nitelikte olmaları, baĢka bir deyiĢle, öteki kütükleri
iĢleyen yordamlarca kullanabilir olmaları gereklidir. Bu yaklaĢım
benimsendiğinde, temel kılavuzları yaratan, silen ve günleyen yazılımın, bu özel
durum için ayrı olarak geliĢtirilmesi ve güncel tutulması zorunludur.
8.3. Fiziksel Düzenleme Kesimi
KYS'nde, fiziksel düzenleme kesiminin üzerinde bulunan katmanlardaki iĢlevler,
g/ç birimlerin fiziksel özelliklerini yansıtan öğeleri kullanmazlar. Bu iĢlevlerde geçen
mantıksal tanımları, ilgili çevre biriminin özelliklerine dönüĢtürmek, fiziksel düzenleme
kesiminin ana görevidir. Bu katman ayrıca, sistem etkinliğini arttırıcı düzenlemeleri de
üstlenir. Programlama dilleri düzeyinde tanımlanan mantıksal kütük yapılarını,
kullanılan birimin özelliklerini gözeterek, baĢarımı arttıracak biçimde fiziksel ortama
uyarlamak, kütüklerin ikincil bellekteki yerleĢim biçimlerini kullanıcılara yansıtmamak,
mantıksal tutanak boylarının fiziksel birimlerden bağımsız saptanmasını sağlamak, g/ç
57
iĢlemlerinde ek tampon alanlar kullanmak, çevre birimine eriĢim sayısını en aza
indirgemek, bu düzenlemelerden en önemlileridir.
8.4. Stratejik Yönetim Kesimi
Stratejik yönetim kesimi, KYS içinde, çevre birimlerine yönelik otamatik
düzenlemelerin yapıldığı katmandır. Çevre birimlerine yöneltilen g/ç istemlerini,
baĢarımını arttıracak biçimde yeniden düzenlemek, mıknatıslı birimlerde yaratılan
kütükler için, bellek atama/geri alma iĢlemlerini yürütmek,bu katmanın ana görevleridir.
GiriĢ/çıkıĢ istemlerinin KYS'nce yeniden düzenlemelerine verilebilecek en
çarpıcı örnek, oynayan okuma/yazma hatalı mıknatıslı tekerlerin yönetimidir. Bu
birimlerde baĢarımı düĢürebilen birincil etken, bir silindirden ötekine geçerken yapılan
kol hareketinde tüketilen süredir. Çok kullanıcılı çalıĢma düzenlerinde, yoğun biçimde
bölüĢülen bu birimlere yöneltilen g/ç istemleri, kullanıcılar düzeyinde rastgele
dağılmaktadır. ĠĢlemler, kullanıcılardan geliĢ sırasına göre iĢlendiklerinde, kol
hareketinin en az zaman kaybettiren biçimde yapılamayacağı açıktır. Örneğin istemler
1., 15. ve 3. silindirlere eriĢimi gerektiren sırada geldiklerinde, 1.silindir üzerinde
bulunduğunu varsayacağımız kolun, (15-1)+(15-3) =26 silindir tutan bir alanda gidip,
gelmesi gerekmektedir. Oysa, bu istemleri 1,3,15 biçiminde sıralandığımızda, toplam 15
silindirlik bir uzaklık aĢılacaktır. Ancak, yeniden düzenleme iĢlemlerinde önlem
alınmasını gerektiren birçok sakınca bulunmaktadır. Örneğin, aynı kütüğe yönelik
iĢlemlerde, okuma/yazma istemlerindeki sıranın değiĢtirilmesi, tutarsız ve hatalı
sonuçlar yaratır. Salt kol hareketini en iyilemeye yönelik bir ölçütün de, sistem
genelinde her zaman baĢarımı arttıracağı söylenemez. Bir önceki örnekte, 3. silindirden
yapılan bir g/ç sırasında 1.silindire yönelik bir istem geldiğini varsayarak kolun iĢlem
yeniden 1.silindire dönmesi gerekecektir. Bu iĢlem sırasında da, 3. silindirdeki bir
kütüğe eriĢim yapan programın istemini yinelediği ve benzer davranıĢın 1. silindirden
g/ç yapan programca da benimsendiğini varsayarak 15. silindire ulaĢım, belirsiz bir süre
ertelenecek, bu g/ç ile ilgili iĢ ise, uzun süre bekletilebilecektir. Mıknatıslı tekerlek ve
öteki çevre birimlerinin baĢarımlarını arttıran dinamik yöntemler, inceleme düzeyimize
göre g/ç birimleri üzerinde daha ayrıntılı bilgi gerektirdiklerinden, konumuz içinde
iĢlenmeyeceklerdir.
Kütüklere, ikincil bellekte yer atamada kullanılan yaklaĢımlar için, iki temel
seçenek vardır. Bunlardan ilki, kütük için gereksenen alanı kütük yaratılırken ard arda
gelen konumları kaplayacak biçimde tümüyle atamak, ikincisi ise, kütüğü gereksemelere
göre parça parça büyütmektir. Ġlk çözümde, kütüğe yer atama iĢlemi yalnız bir kez kütük
yaratılırken yapılmaktadır. Kütüğü oluĢturan alanların ard arda gelmeleri, yer
atama/bırakma iĢlemlerini çok yalınlaĢtırır. Ancak, kütük boyunun önceden saptanması
zor, kimi zaman da olanaksız bir eylemdir. Kullanıcı kütüğü için çok büyük bir yer
ayırdığında, mıknatıslı teker kötü kullanılmıĢ olacak, az yer istediğinde ise, kütüğü
büyütme sorunu ile karĢılacaktır. Bu sorunun çözümü, yer atama iĢleminin gerektirdiği
zaman, salt istemi karĢılayacak sığada yapılmasıdır.
Gereksiz yer kayıplarını önleyen ve kütük büyütme sorununa kesin çözüm
getiren bu yaklaĢımın da bazı sakıncaları vardır. Kütüğü yer atama iĢlemi, g/ç sırasında
parça parça yapıldığından, kütükler için ilk çözüme göre, daha fazla bilginin tutlmasını
58
gerekmektedir. Bunun yanısıra, mıknatıslı teker birçok küçük alana bölündüğünden, yer
atama iĢleminde, uygun bir boĢ alanın bulunması daha zorlaĢmaktadır. Bölünme
arttığında, tüm tekerde yeterli boĢ alan olmasına karĢın, istenen büyüklükteki alanın, tek
bir bütün olarak sağlanamadığı durumlar oluĢabilir. Parçalanma diye adlandırılan bu
olayın giderilmesi için kullanımda olan alanların bir araya toplanmaları gerekmektedir.
Yer değiĢtirme, herhangi bir aksamada birçok kütüğün bozulmasına neden olacağından,
özenle ve önlem olarak, olağan iĢletim dıĢında yürütülmesi gereken, zaman tüketici bir
iĢlemdir.
9. Genel Amaçlı Bir Kütük Yönetim Sistemi
Veri Yönetim Sistemleri’nin çözmek zorunda oldukları belli baĢlı sorunlardan
birinin, kullanıcıların ürettikleri kütük adlarının sistemdeki kimliklere dönüĢtürme
sorunu olduğunu vurgulamıĢtık. Sorundaki ilk güçlükler, mıknatıslı ortamlarda bulunan
kütüklerin isim, içerik ve yaĢam süreleri yönlerinden, kullanıcıların istemlerine göre
rastgele değiĢtirilebilmelerinden kaynaklanmaktadır. BölüĢümden ve herhangi bir
aksamada yeniden baĢlatmak iĢleminden kaynaklanan güçlükler ise, kapsamlı ve
karmaĢık çözümler gerektirdiklerinden, ayrı baĢlık altında iĢlenen konuları oluĢtururlar.
Konumuz çerçevesinde, sorunum salt adlandırma yönüne çözüm getiren, genel
bir sistemin yapısını inceleyeceğiz. Aldığımız örnek, mıknatıslı tekerlerden yaratılan
kütükler için esnek ve yürüyebilir bir alt yapı sağlamaktadır. Bu sistem, bir simgesel
kılavuzdaki kütüklerin değiĢik tekerlere, dağılabilmesini bir çok kullanıcının aynı
kütüğü kendi simgesel evrenine katabilmelerine ve bir kütüğün birden fazla tekere
yayılabilmesini olanaklı kılmaktadır.
9.1. Mantıksal Düzey
Sistemde "VOL1", "VOL2", "VOL3" olarak adlandırılan, üç sökülür/takılır
mıknatıslı tekerin bulunduğunu varsayalım. Bu tekerlerde adları, "FILE" ve "DIR"
örnekleriyle baĢlayan 12 kütük bulunsun. Salt bellenim kolaylığı nedeniyle yaptığımız
bu ayırımda, "FILE" program ve veri kütüklerini, "DIR" ise kılavuzları simgelemektedir.
ġekil-26 bu kütüklerin, tekerlere dağılıĢlarını göstermektedir.
59
Mıknatıslı Teker 1
1.Kullanıcı
Mıknatıslı Teker 2
Mıknatıslı Teker 3
2.Kullanıcı
3.Kullanıcı
VOL1(3)
"FILE3"
"DIR2" VOL2(3)
"FILE2"
VOL2(3)
"DIR3"
"FILE4"
"FILE5"
VOL3(2)
"FILE6"
"DIR4"
"FILE1"
Simgesel Kılavuz
"DIR3"
VOL1(2)
VOL2(4)
VOL1(6)
VOL2(2)
"FILE8"
VOL3(5)
VOL1(4)
"FILE6"
"FILE2"
VOL1(5)
"FILE7"
VOL3(4)
VOL3(3)
ġekil-26. Örnek Sistemde Simgesel Kılavuzlar
Sistemdeki simgesel kılavuzları incelediğimizde, birçok kütük adının (örneğin:
"FILE2", "FILE6","DIR3") ve ayrı kütüğün çeĢitli kılavuzlarda değiĢik adlarla anıldığını
(örneğin: "FILE7", "FILE8", "FILE3" ve "DIR2" ile "DIR4") gözleyebiliriz.
60
Bu örnekte, üç ayrı kullanıcının sırasıyla VOL1(3), VOL2(3), VOL3(2)
kimliklerindeki kütüklerindeki baĢlangıç kılavuzu olarak tanımladıklarını varsayalım.
Buna göre, birinci kullanıcı "FILE2" adını kullandığında VOL1(4) kimliğindeki kütüğe,
üçüncü kullanıcı da "DIR3/FILE2" adıyla VOL3(3) kimliğindeki kütüğe eriĢmektedir.
VOL3(4) kimliğindeki kütük, birinci kullanıcı tarafından: "FILE3" ve
"DIR2/DIR3/FILE8",
ikinci
kullanıcı
tarafından:
"DIR3/FILE8"
ve
"DIR3/DIR3/FILE7", üçüncü kullanıcı tarafından: "FILE8", "DIR3/FILE7" adlarıyla
çağrılabilmektedir.
9.2. Temel Düzey
Bu sistemde kütük kimlikleri, iki simgenin birleĢtirilmesiyle oluĢturulmaktadır:
a)kütüğün bulunduğu tekerin adı, b)kütüğün temel kılavuzdaki konumu. Örneğin
VOL2(3), "VOL2" olarak anılan sökülür/takılır tekerdeki, 3 kimlikli kütüğü, VOL(3)
ise, "VOL3" adlı tekerdeki, 3 kimlikli kütüğü tanımlamaktadır. Temel kılavuzların,
tekerin bilinen bir konumunda, örneğin 0. silindir üzerinde tutuldukları ve her teker
üzerinde 1 nolu kimlikle anıldıkları varsayılmaktadır. Buna göre, her üç tekerin temel
kılavuzu VOL1(1), VOL2(1) ve VOL3(1) kimliği ile anılmaktadır. ġekil-27, iĢlediğimiz
örnek sistemdeki temel kılavuz yapısını göstermektedir.
Bu sistemde, kütük tanımlayıcı tutanakları kurarken temel düzeyin gerçekleĢtiği
iĢlemleri, bir örnek üzerinde inceleyelim. VOL1(3) kimliğindeki kılavuzu baĢlangıç
noktası olan bir kullanıcının, "FILE3" adlı kütüğe eriĢmek istediğini düĢünelim. Kütük
açma iĢlemi sırasında;
a)VOL1(3) kılavuzunun, mıknatıslı tekerden ana belleğe aktarılması,
b)VOL1(3) kılavuzunun, mıknatıslı tekerden ana belleğe aktarılması,
c)kılavuz kütük taranarak, "FILE3" kütüğünün kimliğinin saptanması (VOL3(4),
d)kütüğün bulunduğu mıknatıslı tekere ait (VOL3), temel kılavuzunun
anabelleğe alınması,
e)bu kılavuzun 4 giriĢindeki verilerle, kütük tanımlayıcının oluĢturulması,
gerekmektedir.
Ayrı tekerler üzerindeki bilgileri kullanan bu süreç sırasında, iĢletmenin birçok
mıknatıslı tekeri söküp/takması da gerekebilir. ĠĢletim sisteminin yukarıda sıraladığımız
iĢlevlerinin yanısıra, herbir tekerin hangi sürücü üzerinde bulunduğunu bilmesi ve boĢ
birimlerin durumunu saptanması gerekmektedir.
61
VOL1(1)
VOL1(2)
VOL1(3)
FILE3
VOL3(4)
DIR2
VOL2
FILE2
VOL1(4)
VOL1(3)
FILE4
FILE1
VOL1(6)
VOL1(2)
VOL1(6)
1.Kullanıcı Simgesel
Kılavuz
VOL1(4)
1.Teker Temel
Kılavuzu
VOL2(1)
VOL2(3)
VOL2(2)
VOL2(4)
DIR3
VOL3(2)
FILE5
VOL2(2)
FILE6
VOL2(4)
2.Kullanıcı Simgesel
Kılavuz
2.Teker Temel
Kılavuzu
VOL3(2)
VOL3(1)
3. Teker Temel
Kılavuzu
DIR4
VOL2(3)
DIR3
VOL3(5)
FILE8
VOL3(4)
VOL3(3)
VOL3(4)
Şekil-27. Örnek Sistemde Temel Kılavuzlar
62
FILE6
VOL1(5)
FILE2
VOL3(3)
FILE7
VOL3(4)
Simgesel Alt
Kılavuz
BÖLÜM 4
ANA BELLEK YÖNETĠMĠ
10.1. Ana Bellek Yönetimi ĠĢlevleri
Verilerin içerikleri genellikle kullanıcılar tarafından tanımlanır ve günlenir.
Ayrıca içerik iĢlevinin her komut iĢletiminde benzer biçimde yinelendiği düĢünülürse,
bu iĢlevin sistem açısından çok seçenekli bir yönü olmadığı ortaya çıkar. ġekil-28'de 'A'
ve 'B' iĢlevlerinin zaman içinde ne aĢamada ve nasıl çözümlendiği ise
(Yazılım/Donanım, Yazılım + Donanım, ...) bir bilgisayar sisteminin niteliğini saptayan
en önemli seçeneklerdir.
Kaynak Program
0
Simgesel
LU 4,AA(3)
Çevirici
AA DC . . . .
1000
------XX32
4834
1000
------0003
1000
0005
A
4000
Ana
Bellek
YerdeğiĢir
ĠĢletim
Yükleyici
XX32
4834
5000
5000
B
0003
1000
0005
I
ġekil-28. Bir Programa Uygulanan Bellek Yönetimi
10.1.1. Adlandırma ĠĢlevi
Adlandırma iĢlevi kullanıcıların sorunlarına esnek, kullanımı kolay ve etkin
çözüm sağlamaları için tanınan ayrıĢık simgesel evrenler nedeniyle ortaya çıkmıĢ olup;
bir program içinde değiĢik ortamlarda kullanılan benzer simgesel adların ayrı kimliklere
dönüĢümüdür. Blok yapılı dillerde (PL/1, Pascal gibi) aynı simgenin ayrı bloklarda
kullanımı, bir bilgisayar sisteminden hizmet alan kullanıcıların program, kütük vb.
adlarını birbirinden etkilenmeden seçmeleri adlandırma iĢlevine verebileceğimiz
örneklerdir.
Bir program içinde simgesel adların (değiĢken, kütük adı,...) kimliklere
dönüĢtürülmesi üç yoldan, ayrı ayrı ya da bu yolların bir kesiminin birlikte uygulanması
ile gerçekleĢtirilebilir. Bunlar;
a) Derleme
b) Yükleme
: Simgesel çeviri süresince,
: Öncesinde ya da sonrasında bağlama süresince
63
c) ĠĢletim aĢamasında
ġekil-28'de verilen kodlanmıĢ program örneğinde adlandırılma iĢlevi için 'a' yolu
tümüyle uygulanmaktadır. Aynı örnekte 'AA' simgesinin bir dıĢ iliĢki (External
Referance) simgesi olması baĢka bir deyiĢle bu veri alanının baĢka bir program kesimi
içinde yer alması, çeviri süreci sonunda üretilen amaç programda henüz kimliklerine
kavuĢmamıĢ simgelerin de yer almasına sebep olacaktır. Adlandırma iĢlevinin
tamamlanabilmesi için ayrı bir bağlama sürecine gerek vardır (ġekil- 29).
Kaynak Program
YerdeğiĢir
Amaç Program
EXTERN AA
Simgesel
Çevirici
YerdeğiĢir
Ana Program
XX32
4834
????
AA
XX32
4834
3000
3000
0003
-
Adlandırma ĠĢlevi
ġekil-29 Adlandırma ĠĢlevi
Amaç program içindeki simgeler gerekirse çeviri / bağlama süreçleri bir çok kez
yinelenerek adreslere dönüĢtürülür. Bu yaklaĢım DURGUN (Statik) BAĞLAMA
ĠġLEVĠ olarak adlandırılır (ġekil-30).
Kaynak
Program
Amaç
Program
Simgesel
Çevirici
Simgesel
öğeler
içeren amaç
program
Bağlayıcı
ġekil-30. Durgun Adlandırma ĠĢlevi
64
ĠĢletim aĢamasında bağlama ise, simgesel öğeleri içeren programları iĢletime
alıp, bu öğelere gereksinim duyulduğu zaman bağlama iĢlevini çözümlemeyi öngörür.
Bu yöntem sağladığı etkinliğe karĢın getirdiği yük nedeniyle az benimsenen bir
seçenektir.
10.1.2. Bellek ĠĢlevi
Program içinde göreli adreslerle ana bellekteki gerçek adresler arasında
bağlantıyı kuran bellek iĢlevi, bir bilgisayar sisteminde bellek donanımını belirleyen en
büyük etkendir. Bu iĢlev bir yerdeğiĢir yükleyici yazılım tarafından, iĢletim baĢlamadan
bir kez gerçekleĢtiriliyorsa, ana bellek için 'Durgun Bir Bellek Yönetimi'
uygulanmaktadır. BaĢka bir deyiĢle ana belleğin belirli bir konumuna yüklenmiĢ bir
program, iĢletimi sonuçlanıncaya deyin aynı konumu koruyacaktır. Ana belleğin bir
kaynak sorunu yaratmadığı sistemlerde bu yönetim, yalın olması nedeniyle baĢarı ile
uygulanır. Bu yönetimin sakıncası önceden planlanmıĢ bir stratejinin donmuĢ
yönlerinden kaynaklanan sorunlardır. Ana belleğin iĢletim aĢamasında ortaya çıkan
gereksemelere göre yeniden düzenlenmesi, kaynak sorununu bir ölçüde çözümleyen
esnek bir yaklaĢımdır. Bu olgu programlar açısından bellek iĢlevinin bir çok kez
yinelenebilir olmasına bağlıdır. Bu tür bellek yönetimini ön gören sistemleri 'Dinamik
Bellek Yönetimi' uygulayan sistemler olarak adlandırıyoruz.
Bellek iĢlevi, uygulamada ana belleğin düzenlenmesi ve atanmasını içeren iki
ayrı iĢleve dayanmaktadır. Ana belleğin düzenlenmesini konu kapsamında ayrıntılı
olarak inceleyeceğiz. Bellek atama iĢlevi ise 'Veri Yapıları' konusu içinde ayrıntılı
olarak incelenir, ĠĢletim Sistemleri kapsamında ana belleği bölüĢülen bir kaynak olarak
ele alacağız ve atama iĢlevinin politikası ile ilgileneceğiz. Bellek atamada kullanılan
yöntem ne olursa olsun, bu iĢlevin belli baĢlı dört görevi içerdiği söylenebilir. Bunlar ;
a) Ana belleğin kullanımda/serbest olan kesimlerinin sayıĢımını yapmak,
kullanımda olan kesimlerin ne nitelikte verileri ne süreyle kapsadığını izlemek,
b) Kullanıcıların bellek istemlerini karĢılamak,
c) Kullanımı biten bellek kesimlerini serbest kaynaklar arasına katmak,
d) Gerekiyorsa ana belleği yeniden düzenlemektir.
10.2. Ana Belleğin Düzenlenmesi
Ana belleğin yönetim tekniklerini, bu kaynağı düzenlemekte kullanılan
yöntemlere göre Ģöyle sıralayabiliriz :
1) Single Contiguous
2) Partitioned
3) Relocatable Partitioned
4) Paged
5) Demand-Paged
6) Segmented
7) Segmented And Demand Paged
(Tek ve Kesintisiz)
(Bölümlere Ayırarak)
(Yer DeğiĢir Bölümlerle)
(Sayfalı)
(Ġstenebilir-Sayfalı)
(Kesimleme)
(Kesimleme ve Sayfalama)
65
Bu tekniklerden ilk ikisi 'Durağan', diğerleri 'Dinamik' bellek yönetimi olarak
adlandırılır. Ayrıca, ilk dört bellek yönetimi 'Gerçek', diğerleri 'Görüntü' bellek yönetimi
olarak sınıflandırılır.
Bu teknikleri incelerken Ģu 4 olgu üzerinde duracağız;
1)Tekniğin bellek yönetimine yaklaĢımı, yani kavramlar ve prensipler,
2)Tekniğin gerektirdiği özel donanım,
3)Teknikle ilgili yazılım algoritmaları ve iĢlemlerin (processing) tanıtılıp
incelenmesi,
4)Teknikle ilgili stratejilerin avantajlarının ve dezavantajlarının tartıĢılması.
10.2.1. Gerçek Ana Bellek Yönetimi
10.2.1.1. Single Contiguous (Tek ve Kesintisiz) Bellek Yönetimi
Single Contiguous atama, bellek yönetimi teknikleri içinde en basit olanı ve
dolayısıyla hiçbir özel donanım gereksinimi olmayan bir tekniktir. Bu teknik, IBM-1130
Disk Monitor System, Honeywell 316, PDP-8 ve 9 Monitor Sistemler gibi mini
bilgisayarlarda uygulanmaktadır.
Bu tip sistemlerde Multi Programming söz konusu olmadığından user, job, jobstep ve process olarak tanımlanan kavramlar arasında bire-bir bağlılık bulunmaktadır.
Bu nedenle Single-Contiguous bellek yönetiminden söz ederken user, job, job-step ve
process arasındaki farkları belirtmeksizin sadece process kelimesini kullanabiliriz.
Bu process'e Single-Contiguous atama ġekil-31'deki gibi yapılmaktadır.
ĠĢletim Sistemi
Sistem
Process
Process’e atanan bellek
AtanmıĢ fakat
kullanılmayan bellek
ġekil-31. Single-Contiguous Atama
Kavram olarak ġekil-31'de bellek Contiguous (Kesintisiz) olarak üç bölüme
ayrılmıĢtır. Bunlardan biri kalıcı olarak iĢletim sistemine atanmıĢtır. Geri kalan iki ve
üçüncü bölümler tümüyle tek bir process'e atanmıĢtır. Aslında ġekil-31'de görüldüğü
gibi process sadece ikinci bölümü kullanmakta ve üçüncü bölüm hiçbir Ģey için
kullanılmamaktadır.
Örneğin 256 K byte'lık bir bellek düĢünelim ve bunun 32 K'lık bölümünde basit
bir iĢletim sistemi yerleĢtirilmiĢ olsun. Geriye kalan 224 K'lık bellek tek bir process'e
66
atanmaktadır. Bu process'in 64 K'lık bir sahada çalıĢabileceğini varsayarsak, geriye
kalan 160 K'lık bellek, bu tüm belleğin %60'ı, hiçbir iĢe yaramamaktadır.
Single-Contiguous tekniğine daha önce sözünü ettiğimiz Bellek Yönetim
Fonksiyonları açısından bakacak olursak, bu tekniğin basitliğine karĢın sağladığı
avantajları görebiliriz.
1) Kaynağın, yani belleğin izlenmesi büyük bir sorun değildir, çünkü bellek
tümüyle tek bir process'e atanmaktadır.
2) Bellek atama politikası son derece basittir, bir process'in iĢlenmesine karar
verildiğinde (Scheduled) bellek tümüyle o process'e verilmektedir.
3) Atama iĢlemi son derece basittir.
4) Process'in bellekte olan iĢi bittiğinde tüm bellek baĢka bir process'e atanabilir.
Donanım Desteği
Genel olarak 'Single-Contiguous' atama tekniğinin özel donanıma gereksinimi
yoktur. Ancak bazı sistemlerde process'lerin iĢletim sisteminin çalıĢtığı sahaya
müdahale etmelerini önlemek amacıyla basit bir koruma (Protection) mekanizması
bulunmaktadır.
Bu mekanizma sınırlama registerleri ve CPU'nun supervisor modunda
çalıĢmalarını içermektedir. Sınırlama registerleri adında da anlaĢılacağı gibi iĢletim
sisteminin bulunduğu sahanın bitiĢ adresi ile yüklüdür. Bu register kanalıyla
process'lerin bu sahaya eriĢmeleri önlenmektedir.
CPU genel olarak process ve supervisor olmak üzere iki modda çalıĢır. Process
modunda çalıĢırken donanım process tarafından adreslenen her sahanın korunmaya
alınmıĢ sahanın içinde olup olmadığını kontrol eder. Eğer adresleme sahasının dıĢına
çıkılacak olursa bir interrupt verilir ve kontrol iĢletim sistemine geçer. Supervisor
modunda çalıĢırken ise iĢletim sistemi belleğin her yerini adresleyebilir ve sınırlama
registerlerini set edebilir. Bu moddan diğer bir moda geçiĢ yalnızca iĢletim sistemi
kanalıyla ve genellikle interrupt'larla yapılmaktadır.
Yazılım Desteği
Yazılım yönünden Single-Contiguous atama tekniğinin tek bir algoritma ile
gerçekleĢtirilebileceğini söyleyebiliriz. Bu algoritmanın ana hatlarını akıĢ Ģemasıyla
ġekil-32'deki gibi gösterebiliriz.
67
GiriĢ
Process
<= Bellek
Job Schedular (CPU Yönetimi)
H
Process çalıĢtırılamaz, baĢka
bir process’e
bak
Hata mesajı
E
Job Schedular
Bellek ataması
yap, process’i
yükle ve baĢlat.
Process’in bitiĢinde belleği geri
al ve baĢka bir
process bul.
Job Schedular
ġekil-32. Single-Contiguous Yazılım Algoritması
ġekil-32'de görüldüğü gibi algoritmaya giriĢ, CPU yönetimindeki Job Scheduler
mekanizması tarafından iĢlenmesi istenilen bir iĢ olduğunda yer almaktadır. Bellek
atanması yapıldıktan sonra, atama yapılan process'in iĢi bitinceye kadar algoritmaya
baĢka bir çağrıda bulunulamaz.
Avantajlar
Single-Contiguous atama tekniğinin en büyük avantajı Ģüphesiz çok basit
olmasıdır. Böyle bir teknik normal olarak 1 K'lık bir bellekte gerçekleĢtirilebilir, daha
karmaĢık bir sistemde bellek yönetimi 100-150 K'lık bir bellek kaplayabilir. Diğer bir
avantajı ise, sistemin kullanımındaki kolaylık ve anlaĢılabilirlik olarak gösterilebilir.
Dezavantajları
68
Bu tekniğin en büyük dezavantajı bellekten tümüyle yararlanılmamasıdır. Bu
konuda üç yetersizlik söz edilebilir. Bunlar;
1)Belleğin bir bölümü tümüyle harcanmaktadır.
2)G/Ç kanallarının kullanıldığı bir sistem söz konusu ise, bazı durumlarda
belleğin hiçbir yeri aktif olarak kullanılmamaktadır. ġöyle ki; çalıĢtırılmakta olan
process bir G/Ç iĢlemi baĢlatacak olsa, o G/Ç iĢleminin kanal tarafından yürütüldüğü
süre içinde CPU beklemek zorunluğunda kalacak ve process'in bu süre içinde bellekte
bulunup bulunmaması hiçbir Ģey ifade etmeyecektir.
CPU'nun G/Ç bekleme zamanının yüzdesinin ne olduğu sorusu akla gelebilir.
Doğal olarak bu yüzde programdan programa değiĢir. Örneğin IBM 360-65 modeli bir
makinada tipik bir iĢ için bu oran %60-70 dolayında olmaktadır. Dolayısıyla bellek
kadar CPU'da verimsiz bir Ģekilde kullanılmaktadır.
3)Çoğu programların adresleme sahası içinde bulunan, ancak, ya çok az ya da
hiç kullanılmayan bilgiler taĢıyan bölümleri bulunmaktadır. Örneğin hata mesajları
veren alt-programlar, tanımlanması gereken fakat az veya hiç kullanılmayan sabit
değerler ve buffer sahaları gibi.
Single-Contiguous atama tekniğinin dezavantajları,
1) Verimsiz bellek kullanımı,
2) Verimsiz CPU kullanımı,
3) Process'lerin eldeki bellekten daha küçük bir sahaya yerleĢtirilebilmesi
zorunluluğu ,
Ģeklinde özetlenebilir.
Ġncelenecek olursa Single-Contiguous atama tekniğinin verimsizliği, bir
bilgisayar sisteminin 'DeğiĢmez' olarak nitelendireceğimiz kaynakları ile o sistemi
kullananların 'DeğiĢken' olarak nitelendirebileceğimiz istekleri arasında gereken uyumu
sağlayamamaktan doğmaktadır.
Bir bilgisayar sisteminin fiziksel (Donanım) kaynakları genellikle yılda bir veya
iki kez değiĢikliğe uğramaktadır. Bunun yanında kullanıcıların sistemden istekleri sık
sık değiĢtiği gibi istekler arasında da büyük farklılıklar olabilmektedir. Doğal olarak bu
uyumsuzluğu gidermek için bütün kullanıcıların aynı uzunlukta program yazmaları ve
aynı kaynakları kullanmaları istenemez. Bunu yapmak yerine birden fazla programın
aynı zamanda iĢlenebilmesini sağlama ve kaynakları gerektiği Ģekilde paylaĢımlı olarak
kullanma olanağı sağlanabilir. Bu çalıĢma Ģekline Multi-Programming adını vermiĢtik.
Multi-Programming
Daha önce sözü edilen Multi-Programming, aslında CPU yönetimi kapsamına
giren bir konudur. Ancak bellek yönetimiyle ilgili diğer tekniklerin incelenebilmesi için
Multi-Programming ile ilgili temel kavramların verilmesi gereklidir.
69
Örnek olarak elimizde birbirinden bağımsız üç ayrı iĢin bulunduğunu düĢünelim.
Her iĢ için gereken CPU zamanlarını C1, C2, C3 ve her iĢ için gereken G/Ç kanalı
kullanım zamanlarını ise L1, L2, L3 olarak gösterelim. Ayrıca her iĢin adres sahasını
veya baĢka bir deyimle bellek gereksinimlerini A1, A2, A3 ile gösterelim (ġekil-33).
Ġġ-1
Ġġ-2
Ġġ-3
CPU
C1
CPU
C2
G/Ç
I1
G/Ç
I2
A1=30 K
A2=50K
CPU
C3
G/Ç
I3
A3=20K
ġekil-33. Örnek 3 ĠĢin Gösterimi.
Modelimizi basitleĢtirmek amacıyla her iĢin önce bir süre CPU kullandığını,
ardından bir süre g/ç yaptığını ve tekrar CPU kullanımına döndüğünü varsayalım.
Elimizdeki belleğin kapasitesi 100 K byte olsun. Bu durumda eğer yalnız ĠĢ-1
çalıĢtırılacak olsa 30 K'lık bellek kullanılacak, geriye kalan 70 K'lık bellek boĢ
kalacaktır. Aynı zamanda CPU'nun I1/(C1+I1) oranındaki zamanı g/ç iĢlemlerinin
bitmesini beklemekle geçecektir. Burada I1 ne kadar büyürse CPU bekleme oranı da o
derece büyüyecektir.
Buna karĢın, '(30K+50K+20K)=100K atanabilir bellek kapasitesi' olduğundan,
bütün iĢleri (ĠĢ-1, ĠĢ-2, ĠĢ-3) bellekteki adres sahalarına yerleĢtirebiliriz. Bu belleğin
tümüyle kullanılır hale geçmesini sağlar.
ĠĢler iĢlemeye baĢlandığında CPU yönetimi CPU'yu ĠĢ-1'e atayacaktır. C1 kadar bir
süre geçtikten sonra CPU yönetimi CPU'yu durdurup I1 süresini beklemektense, CPU'yu
ĠĢ-2'ye atayabilecektir. Aynı Ģekilde ĠĢ-2, C2'yi bitirip I2'ye geldiğinde CPU yönetimi
CPU'yu I2 için beklemektense ĠĢ-3'e atayabilecektir.
C3 'ün bitiminde iki durum söz konusudur;
1) I1 <= C2 + C3 ise CPU hiç bekletilmeden ĠĢ-1'e yeniden atanabilir,
70
2) I1 > C2 + C3 ise CPU I1 kadar bir süre beklemektense I1 - (C2 + C3 ) kadar bir
zaman bekletilmiĢ olacaktır.
Görüldüğü gibi Multi-Programming CPU'nun verimliliğini tek bir iĢin
çalıĢtırılması durumundan çok daha arttırmıĢtır. Bazı durumlarda iki veya daha fazla iĢi
aĢağı yukarı tek bir iĢin alacağı süre içinde bitirmek mümkündür.
G/Ç Bekleme Yüzdesinin Ölçülmesi
Buraya kadar kullandığımız "Multi-Programming" modelinde her iĢ için I'ların
ve C'lerin sabit olduğunu ve her I'yı bir C'nin, her C'yi ise bir I'nın izlediğini
varsaymıĢtık.
Aslında gerçek bir process'e iliĢkin I ve C değerleri birbirlerine çok daha
karmaĢık bir Ģekilde bağlıdırlar. Dolayısıyla bir iĢin toplam G/Ç bekleme yüzdesi, ki biz
bunu ile
gösterebiliriz, daha anlamlı ve daha gerçeğe yakın bir ölçü ortaya koymaktadır. Bir iĢin
toplam g/ç bekleme zamanı oranını,
μ = Toplam G/Ç Bekleme Zamanı / Toplam G/Ç + CPU Zamanı
Ģeklinde gösterebiliriz. Bu oran bir iĢin tek baĢına çalıĢtırılabileceği bir sistemde
CPU'nun WAIT statüsüne girdiği zamanları kaydetmek yoluyla kolayca hesaplanabilir.
ĠĢletim sistemleri üzerinde yapılan araĢtırmalarda, orta ve büyük boy (IBM 360/65 veya
IBM 370/158 gibi) sistemlerde çalıĢtırılan tipik iĢlerin
değerinin %60-%70
dolaylarında olduğu gözlenmiĢtir. Doğal olarak bu oran iĢten iĢe değiĢebilir.
"Uniprogramming" yoluyla
değerinin %50 olduğunun saptandığı iki iĢi
"MultiProgramming" ile iĢleyecek olursak sistemin efektif G/Ç bekleme yüzdesinin ( ')
sıfıra düĢeceği söylenebilir mi?
"MultiProgramming" modeline tekrar dönecek olursak, bunun anlamının
C1 I1 C2 I 2 olduğunu görebiliriz. Dolayısıyla I1 ile C2 ve I 2 ile C1 iĢlemleri
çakıĢtırılabilir ve buradan da ( ')'nün sıfıra düĢeceği söylenebilir.
Ancak daha önce belirtildiği gibi bu model yeteri kadar gerçekçi değildir. Daha
iyi bir modellemeyi ġekil-34'teki gibi yapabiliriz.
71
C
C 11
1
I
2
3
4
21
I 22
12
C 13
I 23
I
C
14
= %50
24
1
2
3
4
= %50
1
2
ġekil-34. Multiprogramming Modeli
ġekil-34'te verilen modelde her periyodun C11,I12,C13,... birbirine eĢit olduğu
varsayılmıĢtır. Eğer bu iki iĢi multi programlamaya tabi tutacak olursak I12 ile C21 'i ve
I 22 ile C13 'ü çakıĢtırabiliriz. Ancak ĠĢ-1 I14 durumuna geldiğinde ĠĢ-2 de I 23 durumunda
g/ç yapmak için bekliyor. Bu nedenle CPU’ya I14 veya I 23 iĢleminin yapılması için boĢ
beklemek zorundadır. Görüldüğü gibi değeri %50 olan iki iĢin multiprogramlanması,
sistemin efektif g/ç bekleme yüzdesi 'nün sıfıra inmesi anlamına gelmez..
Bu ikinci multiprogramming modelini genelleĢtirip, olasılık teorisine baĢvuracak
olursak sistemin efektik g/ç bekleme yüzdesine iliĢkin daha anlamlı bilgiler edinebiliriz.
ġöyle ki, sistem g/ç iĢlemlerinin bitmesini ancak bütün iĢlerin g/ç yapmak için uğraĢtığı
bir zamanda beklemek zoruluğunda kalır. Eğer n tane iĢ multi-programlanıyorsa ve her
iĢin g/ç bekleme yüzdesi ( ) birbirine eĢit ise, sistemin toplam g/ç bekleme yüzdesi ( ')
yaklaĢık olarak '= n alınabilir.
Örneğin : Eğer =%50 ise,
ĠĢ Sayısı ( n )
1
2
3
4
5
6
Sistem G/Ç bekleme yüzdesi (μ' )
(0.5)1 %50
(0.5) 2 %25
(0.5) 3 %12.5
(0.5) 4 %6.3
(0.5)5 %3.1
(0.5) 6 %1.6
72
Ancak bu tabloda verilen değerler, her iĢin her periyod içinde bir adım ileri
gittiği varsayılarak elde edilmiĢtir. Eğer sistem N CPU'dan ve N g/ç kanalından oluĢmuĢ
olsaydı bu değerler doğru olacaktı. Fakat bu durumda ' anlamı, N CPU'nun aynı
zamanda boĢ kalma olasılığı olacaktı. Bu olasılığı N tane parayı havaya atıp hepsinin
yazı veya tura gelme olasılığına benzetebiliriz.
Söz konusu bilgisayar sisteminde sadece bir CPU'nun ve birkaç multiplexor g/ç
kanalının bulunduğunu varsayacak olursak N tane g/ç iĢleminin paralel olarak
yürütülebileceğini de varsayabiliriz. Doğal olarak tek bir CPU bulunduğundan CPU'ya
gelen iĢlerde bir yığılma söz konusu olacaktır.
Bu gibi durumlarda olasılık teorisinde "Birth-and-Death Markov Process" i adı
verilen matematiksel bir teknikle çözümlenebilir. Burada sadece "Birth-and-Death
Markov Process" tekniği kullanarak sistemin efektif G/Ç bekleme zamanına daha
geçerli yanıt verecek bir formülü tanıtmakla yetineceğiz.
)n
(
1
n
n!
i 0
)i
(
1
i!
Bu formül ' için '= n formülünden daha düĢük değerler vermektedir. Nedeni
ise n tane CPU yerine sadece tek bir CPU'nun kullanılması varsayımıdır.
Burada belirtilmesi gerekir ki, g/ç bekleme zamanı oranı ile ilgili formüller
bizleri gerçeğe yaklaĢtırıcı nitelikte formüllerdir. Önemli olan nokta g/ç bekleme
zamanının, uygulanacak olan "Multi-Programming" tekniğinin derecesine göre düĢüĢ
göstermesidir. Bundan sonra ele alacağımız bellek yönetim teknikleri "MultiProgramming" tekniğinin uygulanmasını ön planda tutmaktadır.
10.2.1.2. Partitioned (Bölümlere Ayırarak) Bellek Yönetimi
"Multi-Programming" tekniğinin uygulanmasında kullanılabilecek en basit
bellek yönetim tekniklerinden biri Partitioned ( Partisyonlu ) bellek yönetimi tekniğidir.
Adından da anlaĢılacağı gibi partisyonlu bellek yönetiminde bellek birbirinden
bağımsız partisyonlara yani bölümlere ayrılmakta ve her bölüm ayrı bir iĢin adresleme
alanını oluĢturmaktadır (ġekil-35).
73
ĠĢletim Sistemi
ĠĢ-1
Partisyon-1
ĠĢ-2
Partisyon-2
ĠĢ-3
Partisyon-3
Kullanılmayan Bellek
ġekil-35. Partisyoned Bellek Yönetimi.
Donanım Desteği
Genellikle partisyonlu bellek yönetimi az ve basit donanım desteği
gerektirmektedir. Bu donanım özellikle bir iĢin diğer bir iĢe ait adresleme alanına veya
iĢletim sisteminin bulunduğu alana müdahalesini önlemek amacını gütmektedir.
Single-Contiguous bellek yönetimini incelerken sözünü ettiğimiz gibi, bu görev bir
protection (koruma) mekanizması tarafından yapılmaktadır.Yalnız partisyonlu bellek
yönetiminde her partisyon için iki sınırlama registerinin kullanılması gerekmektedir. Bu
registerlerden biri partisyonun üst sınırını diğeri ise alt sınırını belirler (ġekil-36).
74
Bellek
Üst Sınır
......
Adres
Adres
KarĢılaĢtırma
Mekanizması
......
Alt Sınır
ġekil-36. Koruma mekanizması
Multi-Programing yapan bir sistemde g/ç kanallarının da adresleyebilecekleri
alanlar sınırlanmalıdır. Örneğin üçüncü partisyonda bulunan bir iĢ birinci partisyondaki
bilgi okuması için g/ç kanalının adresleyebileyeceği alanlar da iki sınırlama registeriyle
belirlenmelidir. Buna karĢın g/ç kanallarına iliĢkin adresleme iĢleri iĢletim sistemi
tarafından yani yazılım kanalıyla denetlenebilir. Ancak böyle bir yaklaĢım adresleme
zamanı açısından sakıncalı olabilir.
Yazılım Desteği
Uygulamada partisyonlu bellek yönetimi önümüze çeĢitli Ģekillerde çıkmaktadır.
Bunları genel olarak Statik Partisyon'lu ve Dinamik Partisyon'lu teknikler olarak iki
sınıfa ayırabiliriz.
Statik Partisyon'lu uygulamalarda partisyonların yerleri ve büyüklükleri sistem
kullanıma açılmadan önce belirlenmelidir. Örneğin IBM'in OS/370 MFT (MultiProgramming with a fixed number of tasks) adlı iĢletim sisteminde partisyonların sayısı,
yerleri ve büyüklükleri opetatör tarafından sistem on-line duruma gelmeden önce
belirlenmelidir. Örneğin;
75
Partisyon No
---------------1
2
3
4
5
Kapasitesi
------------8K
32K
32K
120K
520K
BaĢlangıç Adresi
--------------------312K
320K
352K
384K
504K
Statüsü
--------1 (Kullanılıyor)
1
0 (Kullanılmıyor)
0
1
Statik Partisyon'lu bellek yönetimi çalıĢtırılacak programların büyüklüklerinin ve
iĢlem frekanslarının bilindiği durumlarda oldukça elveriĢli bir tekniktir. Fakat
programların büyüklükleri ve iĢlem frekanslarının büyük farklılıklar gösterdiği
durumlarda belleğin verimsiz bir Ģekilde kullanılmasına yol açmaktadır. Örneğin;
yukarıda partisyon konumunu belirlediğimiz belleği kullanarak 1 K, 2*9 K, 33 K ve 121
K büyüklüğündeki 5 iĢ için yapılacak bellek atamaları Ģu Ģekilde olabilir;
Partisyon No
---------------1
2
3
4
5
Kapasitesi
------------8K
32K
32K
120K
520K
---------712K
ĠĢ Büyüklüğü
Statüsü
--------------------------1K
1 (Kullanılıyor)
9K
1
9K
0 (Kullanılmıyor)
33K
0
121K
1
----------------173K
539K
Görüldüğü gibi iĢlerin partisyon kapasitelerine en uygun bir Ģekilde
yerleĢtirilmelerine rağmen 712 K'lık belleğin yalnız 173 K'lık bölümü, yani %25 i
kullanılmakta geri kalan %75 i ise hiçbir iĢe yaramamaktadır. Bu örnek abartılmıĢ gibi
görünüyorsa da gerçek uygulamalarda benzeri oranda bellek harcanması kolaylıkla söz
konusu olabilmektedir.
Statik Partisyon'lu uygulamalarda önümüze çıkan bu gibi iĢ büyüklüğü partisyon
kapasitesi uyumsuzluğunu gidermek amacıyla Dinamik Partisyon atama teknikleri
geliĢtirilmiĢtir.
Dinamik Partisyon'lu uygulamalarda partisyonların sayısı büyüklükleri ve
bulundukları yerler sisteme girilen iĢlere bellek gereksinimlerine göre yani dinamik
olarak belirlenmektedir (ġekil-37).
76
(a)
(b)
ĠĢlt. Sistemi
312 K
(c)
ĠĢlt. Sistemi
312 K
ĠĢ-1
ĠĢ-1
8K
320 K
312 K
8K
320 K ĠĢ-1
320 K
ĠĢ-2
ĠĢ-2
ĠĢ-2
32 K
32 K
352 K
352 K
ĠĢ-4
ĠĢ-4
BoĢ
BoĢ
32 K
BoĢ
352 K
32 K
376 K ĠĢ-4
24 K
8K
BoĢ
384 K
ĠĢ-3
8K
24 K
376 K
384 K
ĠĢlt.
Sistemi
ĠĢ-3
120 K
504 K
120 K
504 K
ĠĢ-5
BoĢ
128 K
504 K
ĠĢ-5
128 K
632 K
632 K
128 K
ĠĢ-6
ĠĢ-6
256 K
520 K
888 K
888 K
128 K
BoĢ
BoĢ
136 K
1024 K
1024 K
1024 K
ĠĢ-4 : 24 K
ĠĢ-5 : 128 K
ĠĢ-6 : 256 K
ġekil-37. Dinamik Partisyonlu Uygulamalarda Bellek Atama.
77
136 K
Belleğin herhangi bir andaki durumunu ġekil-37a'da gösterildiği gibi varsayalım.
Burada bulunan üç iĢ için o iĢlerin büyüklüklerine eĢit büyüklükte üç partisyon atanmıĢ
olsun. Bir süre sonra üç ayrı iĢin daha sisteme girilmesi istendiğini varsayalım. Bu yeni
iĢin belleğe yerleĢtirilmesi ġekil-37b'de gösterildiği gibi olabilir. Yine bir süre sonra ĠĢ-2
ve ĠĢ-3 ün bittiğini varsayarsak belleğin bu iĢlerin devreden çıkmasından sonraki
durumu da ġekil-37c'de gösterildiği gibi olacaktır.
Görüldüğü gibi yeni bir iĢe partisyon ataması yapılırken izlenen yöntem;
1) Kapasitesi en az iĢin büyüklüğüne eĢit olan bir partisyonun bulunması,
2) Eğer partisyon kapasitesi iĢten büyükse, iĢe yetecek sahanın atanması ve geriye
kalan kısmın ise boĢ bırakılması,
dır.
Benzer olarak iĢi biten partisyonların tekrar kullanılmak için sisteme
kazandırılmasında izlenen yöntem ise; herhangi bir partisyon boĢaltığında o partisyona
komĢu olan partisyonların kullanılıp kullanılmadığının kontrol edilmesi, eğer
kullanılmayan varsa boĢalan partisyonun onlarla birleĢtirilmesidir.
Buraya kadar söylenenlerden anlaĢılacağı üzere, Dinamik Partisyon atama
uygulamalarında belleğin hem kullanılan hemde kullanılabilecek durumda olan
bölümleriyle ilgili statü bilgilerinin tutulması gerekir. Örneğin, belleğin ġekil-37a'daki
durumundaki statüsünü Ģu Ģekilde tutabiliriz.
AtanmıĢ Partisyonların Statüsü
Partisyon No
---------------1
2
3
4
5
.
.
.
Kapasite(K)
--------------8K
32K
120K
.
.
.
Adres(A)
-----------312K
320K
384K
.
.
.
Statüsü
---------1 (AtanmıĢ)
1
* (BoĢ Bilgi Alanı)
1
*
*
*
*
Bellek statüsü ile ilgili bilgilerin bu Ģekilde tutulduğunu varsayarak Dinamik
Partisyon'lu bellek yönetiminde partisyon atamalarının (Kaynak Atanması) ve iĢi biten
partisyonların tekrar sisteme kazandırılması (Kaynağın Geri Alınması) iĢlemlerinin nasıl
yapıldığını algoritmik olarak inceleyelim.
78
Dinamik Partisyon Atama Algoritması
λ K uzunluğunda
bir partisyon isteği
B=1
B = B+ 1
ġu anda partisyon
ataması yapılamıyor
E
B=Son
alan ?
H
H
B=Atanabilir mi?
E
Adres = B{A}
<
B(k)>=λK
>
B(K) = B(K) – λK
B(A) = Adres+λK
B(s) = *
P(s) = * bir yer bul
P(K) ve P(A)
değerlerini
yaz
P(s) = 1 (AtanmıĢ)
Partisyon numarası
P(N) ile dön
79
Dinamik Partisyon Geri Alma Algoritması
Partisyon P(N)’i
boĢaltma isteği
Büyüklük = P(K)
Adres = P(A)
P(s) = *
BoĢ komĢu yok
B(s) = * olan
bir yer bul
P’nin boĢ
komĢuları
var mı?
1 BoĢ (B1)
2 BoĢ (B1 ve B2 arası)
B1(K) = B1(K) + B2(K) +
P(K)
B1(K) = B1(K) + P(K)
B(K) = P(K)
B(A) = P(A)
B(s) = 0 (BoĢ)
DÖN
Gerçek sistemlerde Dinamik Partisyon atama uygulamaları iki ayrı Ģekilde
karĢımıza çıkmaktadır. Bunlardan biri First- Fit (ilk-uygun), diğeri ise Best-Fit
(en-uygun) atama teknikleri adları ile bilinmektedir.
80
Algoritmik yönden ele alınacak olunursa her iki teknikte yukarıda incelediğimiz
algoritmanın aynısını incelemektedir. Ancak First-Fit tekniğinde kullanılan boĢ alanlar
listesi, bu alanların adreslerine göre dizilmiĢlerdir; yani en küçük adresliden en büyük
adresliye doğru sıralanmıĢtır. Yeni bir partisyon istendiğinde arama en iĢlemi en küçük
adresli boĢ alandan baĢlatılmakta ve karĢılaĢılan ilk yeterli boĢ alan istenilen partisyonu
oluĢturmaktadır.
First-Fit tekniğinin belli baĢlı iki avantajı vardır:
1) Partisyonu geri alma algoritmasında belirtilen " bu partisyona komĢu baĢka
boĢ alan var mı? " sorusuna yanıt verebilmek için ortalama olarak boĢ alanlar listesinin
sadece yarısını taramak gerekiyor. Bunun yanında eğer varsa küçük adresli boĢ komĢu
alan, ilk bulunan alan olmaktadır.
2) Bu teknik mümkün olduğu kadar belleğin küçük adresli bölümlerindeki boĢ
alanların kullanılmasını sağlamaktadır. Böylelikle kapasitesi büyük olan boĢ alanlar
belleğin büyük adresli bölümlerinde oluĢup, birikim özelliği göstermektedirler.
Dolayısıyla büyük bir iĢ için partisyon istendiğinde belleğin bu bölümünde istenilen
büyüklükte bir partisyon oluĢturulması Ģansı büyümektedir.
Best-Fit tekniğinde ise boĢ alanlar listesi, alanların kapasitesine göre
sıralanmıĢtır; yani en küçük kapasiteli boĢ alan listenin baĢında, en büyük kapasiteli boĢ
alan ise listenin sonunda yer almaktadır. Böylelikle bir iĢ için partisyon istenildiğinde
yapılacak iĢ, listenin baĢından baĢlayarak o iĢ için yeterli olabilecek ilk boĢ alanın
hangisi olduğunu bulmaktır. Bulunan bu boĢ alan aynı zamanda o iĢ için en uygun
(Best-Fitted) partisyon olmaktadır. Best-Fit tekniğinin belli baĢlı üç avantajı vardır.
Bunlar;
1) Ortalama olarak Best-Fit sağlayan boĢ alanı bulmak için boĢ alanlar listesinin
sadece yarısını taramak gerekiyor,
2) Eğer tam istenilen kapasitede olan bir boĢ alan varsa Best-Fit tekniği bu alanı
bulmaktadır. First-Fit tekniğinde aynı seçimin yapılması söz konusu olmayabilir.
3) Eğer tam istenilen kapasitede bir boĢ alan yoksa ona yakın (en-uygun) boĢ
alan seçilir ki, bu da First-Fit tekniğinde görülen gereğinden büyük boĢ alanların
parçalanmasını önler ve bu gibi alanların daha büyük iĢler için kullanılması Ģansını
arttırır.
Ancak, burada Ģunu da belirtmek gerekir ki, Best-Fit kriteri sağlanırken, her
zaman istenilen boĢ alana en yakın seçildiğinden bellekte hiçbir iĢe yaramayacak kadar
küçük boĢ alanlar oluĢmaktadır. Bu durumuda Best-Fit tekniğinin bir dezavantajı olarak
vurgulamak gerekir.
Partisyonlu bellek yönetimi uygulamarının bir sonucu olarak bellekte birbirinden
ayrı irili ufaklı boĢ sahaların oluĢması olayına Fragmantasyon denir.
ġekil-37c'de verdiğimiz Dinamik Partisyon atama örneğine dönecek olursak
atanabilecek en büyük partisyon alanì 136 K büyüklüğündedir. Bu durumda 137 K'lık
bir partisyon istenecek olsa, Ģimdiye kadar incelediğimiz algoritmalardan "Yer Yok!"
81
yanıtını alacaktık; bellekte toplam 296 K'lık boĢ alan bulunmasına rağmen isteğimiz
karĢılanmayacaktır.
Partisyonlu bellek yönetiminde algoritma seçiminin dikkatli yapılmasıyla
fragmentasyon sorununun etkisi minimum bir düzeyde tutulabilir. ġimdiye kadar
incelediğimiz statik partisyon, dinamik First-Fit ve dinamik Best-Fit atama
tekniklerinden herbirinin fragmentasyon sorununun etkilerini minimum bir düzeyde
tutacak uygulamalar bulmak mümkündür.
Örneğin Ģöyle bir iĢ akıĢı söz konusu olsun;
ĠĢ-1
ĠĢ-2
ĠĢ-3
ĠĢ-1
ĠĢ-3
ĠĢ-4
ĠĢ-5
.
.
.
140 K
16 K
80 K
Sonuçlanıyor
Sonuçlanıyor
80 K
128 K
ġimdi elimizde 256 K'lık belleğin bulunduğunu varsayarak üç algoritmanın
hangisinin bu iĢ akıĢı için elveriĢli olacağını araĢtıralım (ġekil-38).
150 K
Tıkanma yok, algoritma geçerli.
ĠĢ-1
ĠĢ-5
80 K
26 K
ĠĢ-3
ĠĢ-4
ĠĢ-2
a) Statik Partisyon Atama
82
140 K
16 K
ĠĢ-1
ĠĢ-2
80 K
60 K
16 K
80 K
ĠĢ-4
ĠĢ-2
Tıkanma var,
ĠĢ-5 için partisyon yok.
ĠĢ-2 veya
ĠĢ-4’ün sonuçlanmasını
beklemek gerekiyor.
ĠĢ-3
100 K
20 K
b) Dinamik First-Fit.
140 K
128 K
ĠĢ-1
16 K
80 K
ĠĢ-5
Tıkanma yok,
algoritma
geçerli.
12 K
ĠĢ-2
ĠĢ-3
16 K
ĠĢ-2
80 K
ĠĢ-4
20 K
20 K
c) Dinamik Best-Fit
ġekil-38. Partisyonlu Bellek Yönetim Algoritmalarının KarĢılaĢtırılması
ġekil-38'de görüldüğü gibi, Dinamik First-Fit tekniği statik partisyon atama
tekniğine göre daha mantıklı bir teknik olmasına karĢın ele aldığımız iĢ akıĢı için statik
partisyon atama tekniğinin daha elveriĢli (tıkanma yaratmayan) bir teknik olduğunu
söyleyebiliriz. Sonuç olarak bir tekniğin diğerinden daha iyi olup olmadığını
söyleyebilmek için sisteme girilecek iĢlerin sırasını, büyüklüklerini ve iĢlem
frekanslarını bilmek veya bu konuda tahminler (istatistikler) yürütmek gerekmektedir.
83
Avantajlar
Partisyonlu bellek yönetiminin belli baĢlı üç avantajı vardır. Bunlar;
1) Multi-Programming'e elveriĢli bir bellek yönetim tekniğidir, dolayısıyla CPU
ve g/ç ünitelerinin daha verimli bir Ģekilde kullanılmasını sağlar,
2) Özel amaçlı ve karmaĢık bir donanım gerektirmez,
3) Teknik ile ilgili yazılım algoritmaları oldukça basittir.
Dezavantajlar
1) Partisyonlu bellek yönetiminin en büyük dezavantajı fragmentasyondur.
Fragmentasyonun etkisi kullanılacak olan bellek atama algoritmasına ve sisteme
girilecek iĢlerin sıralanmasına baĢlı olarak değiĢir. Öyle iĢ sıralanmaları düĢünülebilinir
ki, bellek kullanımı %10 un altına düĢmektedir.
2) Single-Contiguous bellek yönetimine kıyasla hem daha büyük bir iĢletim
sistemi hem de daha fazla bellek gerektirir.
3) Bir iĢ için gerekecek partisyonun büyüklüğü bellek kapasitesi ile
sınırlanmaktadır. Ayrıca Single-Contiguous tekniğinde olduğu gibi bellekte çok az ve
hatta hiç kullanılmayacak olan bir takım bilgilerde tutulmaktadır.
Bellek Gereksinimi
Genelde ne kadar bellek satın alınmalıdır? sorusuna yanıt verirken iki faktör göz
önünde tutulmalıdır;
1) Sisteme girilecek iĢlerin ortalama uzunlukları,
2) Ġstenilen CPU kullanım yüzdesi.
1970-71 yılında LEHMAN tarafından IBM 360/65 ve 370/155 sistemleri
üzerinde yapılan bir araĢtırmaya göre tipik bir iĢ 128 KB'lık bir bellek istemekte ve tek
baĢına çalıĢtırıldığında, bu iĢ toplam zamanının %65’ini g/ç beklemekle geçirmektedir.
Multi-Programming konusunu incelerken gördüğümüz gibi, efektif sistem g/ç
oranını %10’un altına düĢürebilmek için en azından dört iĢin multi-programlanması
gerekir. ' ile ilgili tabloya bakılacak olunursa;
=%65
N=4
N=5
N=6
için
için
için
'=8.1
'=2.9
'=0.9
N=5 alınacak olunursa bellek gereksinimi 5*128=640 K olur. Doğal olarak
partisyonlu bellek yönetiminde fragmentasyon söz konusu olduğundan extra belleğe
84
gereksinim vardır. Fragmentasyon ile belleğin 1/3’ünün harcandığını varsayacak
olursak, bellek kapasitesinin 640+320=960 K olması gerekmektedir. Buna iĢletim
sistemi için gerekecek belleği de eklemek gerekir, bu da yaklaĢık olarak 256 K ile 512 K
arasında değiĢebilir.
10.2.1.3. Relocatable Partitioned (Yer DeğiĢir Bölümlü) Bellek Yönetimi
Belleği bölümleyerek (Partitioned) düzenleme yönteminin en büyük sakıncası,
ana belleğin parçalanmasıdır (Fragmentesyon). ĠĢletim sırasında iĢlerin nasıl
davranacağı tam kestirilemediği için, yapılan planlamalarda yetersiz kalmaya
mahkumdur. Sorun bellek yönetiminde uygulanan politikanın durgun olmasından
kaynaklanmaktadır. BaĢka bir deyiĢle iĢlerin, iĢletime baĢladıkları yerde bilinmeleri
gerekmektedir. Oysa parçalanmaların arttığı dönemlerde kullanılan alanların ana
bellekte kaydırılıp ard arda dizilmelerine olanak tanınsaydı serbest alanların
bütünleĢmesi gerçekleĢtirilebilirdi (ġekil-39).
Ýþletim
ĠĢletim Sistemi
Sist.
Ýþletim
ĠĢletim Sistemi
Sist.
Ýþletim
ĠĢletim Sistemi
Sist.
ĠĢ-1
Ýþ-1
BoĢ
Boþ
ĠĢ-2
Ýþ-2
ĠĢ-2
Ýþ-2
ĠĢ-2
Ýþ-2
ĠĢ-4
Ýþ-4
ĠĢ-3
Ýþ-3
BoĢ
Boþ
ĠĢ-4
Ýþ-4
ĠĢ-4
Ýþ-4
ĠĢ-5
Ýþ-5
BoĢ
Boþ
a)
Baþlangýcý
a) Ýþletim
ĠĢletim BaĢlangıcı
BoĢ
Boþ
b)
iþlerin
b) 1,3
1, 3 ve
ve 5.
5. ĠĢlerin
Sonuçlanmasý
Sonuçlanması
c)
Yeniden Düzenleme
c) Yeniden
Düzenleme
ġekil-39.
Þekil
: 39.Belleğin
Belleðin Düzenlenmesi
Düzenlenmesi(Compaction).
( Compaction )
Ana bellekte iĢletim aĢamasında yapılan bu kaydırma, dinamik bir bellek
yönetim politikasını gerekmektedir. Çünkü yeri değiĢtirilen programların içerdikleri
adreslerin yeniden belirlenen bir baĢlangıç adresine göre düzenlenmeleri yeterli
olmayacaktır. ĠĢletim sırasında hesaplanan veri adresleri, iĢletim baĢlangıcındaki
konuma göreli değer olacaklardır.
Böyle bir iĢlem prensip olarak basit olmasına karĢın uygulamada çeĢitli sorunlara
yol açmaktadır. ġöyle ki, bir iĢin adresleme alanı değiĢtirildiğinde o iĢin yeni adresleme
alanında da doğru olarak çalıĢacağı söylenemez. Çünkü her iĢte veya programda base
register'ler, parametre listeleri, data yapıları (Listeler, Kuyruklar, Stackler) gibi adres
duyarlı elemanlar bulunmaktadır. Dolayısıyla yerdeğiĢiminden sonra bir programın
doğru olarak çalıĢmasına devam etmesini sağlamak için o programa iliĢkin adres duyarlı
elemanlarında gerektiği Ģekilde yeniden düzenlenmesi gerekir. ĠĢte adres duyarlı
85
elemanların yer değiĢtirmesi iĢlemine Relocation adı verilmektedir. Ancak relocation
iĢlemi göründüğünden çok daha büyük bir sorun olarak karĢımıza çıkmaktadır. Bir
programda kullanılan adres ve pointerlardan hangilerinin değiĢtirilmesi gerektiğini bir
iĢletim sistemi nasıl tayin edebilir? Programın içinde 364000 gibi sayısal bir değerin
olduğunu varsayalım, acaba bu relocation sırasında değiĢtirilmesi gereken bir adres
midir yoksa programa veri olarak verilmiĢ bir telefon numarası mıdır ?
Bu tip ayırımı yapabilmek için özellikle Reiter (1966-67) tarafından çeĢitli
yazılım teknikleri geliĢtirilmiĢtir. Ancak bu teknikler verimsiz ve kısıtlayıcı olmaları
nedeniyle geniĢ çapta uygulanamamaktadırlar.
Relocation sorununa baĢka bir yaklaĢımla yer değiĢtirecek programların yeniden
yüklenmesi ve iĢlemlerine yeniden baĢlatılması olabilir. (Relocatable Loader) Ancak bu
yaklaĢımla CPU nun etkin kullanımı söz konusu olamayacağı gibi, bazı durumlarda bir
iĢe yeni baĢtan baĢlamamız da mümkün olmayabilir.
Relocation sorununa en uygun çözüm 'Donanım' veya 'Mapped memory'
teknolojisinden kaynaklanmaktadır. Bu teknolojinin temel kavramını Ģu Ģekilde
özetleyebiliriz;
Bir programın kendisine ait olarak gördüğü adresleme alanı o programın
çalıĢtırıldığı belleğin fiziksel (gerçek) adresleme alanıyla aynı olmayabilir (ġekil-40).
0
1024
1024
256
+
1280
512
1536
ġekil-40. Taban Yazmacına Göreli Adresleme
Þekil : 40. Taban Yazmacýna Göreli Adresleme
Aslında bu kavram Virtual Memory veya Görüntülü Bellek adını verdiğimiz
kavramın temelini oluĢturmaktadır.
Donanım Desteği
Relocatable Partitioned bellek yönetiminin gerektirdiği relocation iĢlemine
donanım yönünden iki ayrı Ģekilde yaklaĢılabilir.
Bunlardan biri Data Tipi kavramı üzerine kurulu olup, bellekteki her değerin ne
tip data olduğunu fiziksel olarak kaydetmeye dayanmaktadır. Örneğin her bellek
86
kelimesine (Word) iki extra tag biti eklenmekle kelimelerdeki data tipini bu bitler
yardımıyla belirtebiliriz. Örneğin;
00 : Integer
01 : Floating Point
10 : Karakter
11 : Adres
Bu bitler programcılar tarafından görülmemekte ve donanım tarafından otomatik
olarak belirlenip iĢlenmektedir. Örneğin "A" adres değeri taĢıyan, "I" ise integer değer
taĢıyan değiĢkenler olsun. I=A gibi bir deyim iĢlendiğinde A' nın değeri I'ya taĢındığı
gibi A'nın tipini belirten (11) değeri de I'nın tipini belirten (00) değerinin yerine
taĢınmaktadır. Böylece adres değerlerinin relocation amacıyla yer değiĢtirmesi ve
iĢlenmesi sağlanmıĢ olmaktadır.
Bir iĢe iliĢkin partisyonun yer değiĢtirmesi gerektiğinde donanım, data tipini
belirten bitlere bakarak adres tipini bulmakta ve bunlar üzerinde gereken relocation
iĢleminin yapmaktadır. Burroughs 5500 ve 6700 serisi bilgisayarlarda bu tip bir
relocation donanım mekanizması kullanılmaktadır.
Data tiplerini belirleyerek relocation yapmanın belli baĢlı üç dezavantajı vardır.
Bunlar;
1)Her kelime için iki extra tag bitinin sağlanması,
2)Her kelimenin data tipi kontrol edildiğinden relocation iĢlemi yavaĢ
olmaktadır,
3)Günümüz bilgisayarlarınıın çoğunun genel yapısından ayrıcalık gösteren bir
yapı oluĢturduğundan "incompatibility" veya uyumsuzluk sorunları ortaya çıkmaktadır.
Diğır bir relocation tekniğinde ise sistem, Base Relocation ve Bounds
registerleri olarak bilinen iki özel amaçlı registerle donatılmıĢtır. Dec PDP-10, Univac
1108 ve Honeywell 6000 serisi bilgisayarlarda kullanılan bu teknikle relocation
iĢleminin nasıl yapıldığını bir örnekle inceleyebiliriz. Bellekte 352 K ile 376 K adresleri
arasında yerleĢtirilmiĢ bir iĢ düĢünelim (ġekil-41).
87
352 K
350800
370248
Efektif
Adres
Load 1,370248
Relocation
Relucation
Register
Register
00000
352K
370248
Load 1,370248
370248
ĠĢin
Ýþin
Partisyonu
015571
376 K
+
ĠĢin Adres
Ýþin
Adres Sahası
Sahasý
Processor
Yönü
370248
Bellek
Yönü
015571
376 K
Yönü
1024 K
Fiziksel Bellek
A) Relocationdan Önce
352 K
350800
370248
Efektif
Adres
Load 1,370248
Relocation
Relucation
Register
Register
-32768
352K
328032
Load 1,370248
ĠĢin
Ýþin
Partisyonu
Partisyonu
370248
015571
376 K
+
ĠĢin Adres
Ýþin
Adres Sahası
Sahasý
Processor
Yönü
337480
Bellek
Yönü
015571
344 K
Yönü
1024 K
Fiziksel Bellek
B) Relocationdan Sonra
ġekil-41.
Relocation
Register’ın
Kullanımı
Þekil 41. Relocation
registerin
kullanýmý
ġekil-41'de görüldüğü gibi bu yöntemde program içinde belirlenmiĢ olan
adreslerde herhangi bir değiĢiklik yapılmadığı gibi, program bellekteki fiziksel (gerçek)
konumunun da farkında olmadan çalıĢtırılabilmektedir.
Relocation iĢleminin otomatik olarak ve her komutun iĢlenmesi sırasında
yapılması nedeniyle bu tekniğe Dinamik Relocation adı verilmektedir. Bounds registeri
ise koruma amacıyla sınırlama registerlerinde olduğu gibi kullanılmaktadır.
Yazılım Desteği
88
ġekil-41'den anlaĢılacağı gibi dinamik relocation tekniği kullanıldığında, bir iĢe
ait adresleme alanı o iĢin bellekteki gerçek konumundan bağımsız olarak düĢünülebilir.
Dolayısıyla her iĢin adresleme alanı sıfırdan baĢlatılabilir (ġekil-42).
Bounds
Register
24 K
0
Efektif
Adres
352
Load 1,9800
9800
015571
Relocation
Register
352 K
352K
360800
Load 1,370248
ĠĢin
Ýþin
9800
Partisyonu
24 K
+
370248
015571
AdresSahasý
Sahası
Adres
376 K
1024 K
Fiziksel Bellek
ġekil-42.
ĠĢin42.Adresleme
Alanı
Sıfırdan
BaĢlatılıyor.
Þekil
Ýþin Adresleme
alaný
sýfýrdan
baþlatýlýyor.
Relocatable partisyonlu bellek yönetiminde kullanılan algoritmalar, temel olarak
dinamik partisyonlu bellek yönetimini anlatırken incelediğimiz algoritmaların aynıdır.
Ancak burada ek olarak bir de "Compaction ne zaman yapılacak?" sorusuna yanıt
vermek gerekiyor. Bu soruyu yanıtlamak için iki ayrı yol izlenebilir.
Bunlardan birinde compaction iĢlemi bir partisyon boĢaldığında hemen
yapılmakta ve fragmantasyona fırsat verilmemektedir. Böyle bir yaklaĢımla boĢ
alanların tümünün bir arada tutulması sağlandığı gibi boĢ alanlar listesi üzerinde
yapılacak iĢlemler de basitleĢtirilmiĢ olmaktadır. Ancak compaction iĢleminin her
partisyon baĢladığında yapılmasının CPU zamanı açısından sakıncaları vardır. Örneğin
bir partisyonu bir yerden diğer bir yere taĢırken saniyede bir milyon byte transfer
edebileceğimizi düĢünecek olursak (IBM-370 MVC veya MVCL komutları ile), 1024
K'lık bir belleğin ortalarına doğru olan küçük bir partisyonun yerini değiĢtirmek için 1/2
saniyelik CPU zamanı gerekecektir. ĠĢ CPU zamanından büyük olabilir.
Diğer bir yöntem ise recompaction iĢleminin sadece yeni gelen bir iĢ için
gereken yeterli boĢ bir alanın bulunmadığı zamanlarda yapmak olabilir. Böylelikle
compaction için kullanılacak olan CPU zamanında önemli derecede düĢüĢ olacaktır.
Fakat buna karĢın boĢ alanlar listesi ve partisyonlar listesi üzerinde yapılacak olan
iĢlemler daha karmaĢık ve zaman alıcı olacaktır.
Görüldüğü gibi bu iki yöntem arasında bir seçim yapabilmek için sisteme
girilecek iĢlerin büyüklükleri ve iĢlem frekansları ile ilgili bilgiler göz önünde
tutulmalıdır. Relocatable partition bellek yönetiminde partisyon atama algoritması
ġekil-43'te verilmiĢtir.
89
λK büyüklüğünde
partisyon istemi
BoĢ Saha
>= λK
?
E
Partisyon ata ve
tabloları düzenle
Partisyon no ile
dön.
H
Partisyon ataması
yapılamaz.
H
Toplam
BoĢ Saha
>= λK
E
Bellek parçalarını birleĢtir ve
tabloları günle
( Tek boĢ saha >= λK)
ġekil-43. Relocatable Partition Atama Algoritması
Avantajlar
Relocation partisyonlu bellek yönetiminin belli baĢlı avantajlarını Ģu Ģekilde
sıralayabiliriz;
1) Fragmantasyon sorununu ortadan kadırır,
2) Daha çok sayıda partisyonun atanmasını sağlar,
3) Multi-Programming uygulama düzeyini yükseltir,
4) Bellek ve CPU kullanım oranını arttırır.
Dezavantajları
1) Relocation donanımı sistemin fiatını yükseltir,
2) Relocation donanımı sistem hızını azaltır,
3) Compaction zamanı yüksek olabilir,
4) Compaction yapılmasına rağmen bazı bellek bölümleri kullanılmayacaktır
(Ya iĢ giriĢi olmadığından veya yeteri kadar boĢ bir alan bulunmadığından ),
5) Atanabilecek partisyon kapasitesi bellek kapasitesi ile sınırlanmaktadır.
90
10.2.1.4. Paged (Sayfalı) Bellek Yönetimi
Ana belleği yerdeğiĢtirir bölümlerle düzenlemek, parçalanmayı önlemesine
karĢın iĢletimin zaman zaman kesilerek bölümlerin ana bellekte kaydırılmaları nedeniyle
pahalı bir çözümdür. Yöntemi bu açıdan incelediğimizde bunu, iĢlere atanacak kesimin
tek bir bütün olarak iĢlenmesinden kaynaklandığını kolayca görebiliriz. ĠĢlere atanacak
bellek kesiminin devamlı olması zorunluğu ortadan kaldırıldığında parçalanmayı
önleyici daha etkin teknikler geliĢtirilmiĢtir. Bunlardan biri paging (Sayfalama) bellek
yönetim tekniğidir.
Sayfalama yönteminin temelini adresleme alanı ile fiziksel alanın birbirinden
bağımsız olabileceği düĢüncesi oluĢturmuĢtur. Bağımsızlık kavramını fragmantasyon ve
devamlılık açısından en iyi bir Ģekilde değerlendirebilmek için adresleme alanı ve
fiziksel alan eĢit uzunlukta küçük parçalara bölünmüĢtür. Adresleme alanının küçük
parçalarına "page", fiziksel alanın küçük parçalarına ise "blok" adı verilmektedir. Böyle
bir yapı içinde bir öğenin adresi, içinde bulunduğu sayfa no ve sayfa baĢına göreli
konumu olarak saptanır (ġekil- 40).
0.Sayfa
α öğe adresi
öðe adresi(Sayfa
) 1,
(Sayfa
1, α)
1.sayfa
ġekil-40.
Þekil:40. Bir
Bir Öğenin
öðeninGöreli
göreliKonumu
konumu
Mantıksal açıdan bakıldığında öğelerin program baĢlangıcına göreli konumları
değiĢmektedir. Örneğin sayfa boyu x bellek birimi ise, öğesinin program baĢına göreli
adresi;
Sayfa-No * x +
yada "x+ " dır.
Dinamik bellek yönetiminin ilkesini "programların adres alanlarının ana belleğin
fiziksel konumlarından bağımsızlaĢtırmak" diye tanımlamıĢtık. Sayfalama yöteminde,
bu ilkeyi "bir sayfa içindeki konumlarından bağımsızlaĢtırmak" olarak geniĢletiyoruz.
91
Relocatable bellek yönetiminden hatırlanacağı gibi gereken önlemler alındığında
(Base Register) partisyonların bellekteki fiziksel konumu iĢlerin adresleme alanlarını
etkilememektedir. Bu gerçek göz önünde tutularak page'ler ile blok'lar arasında öyle bir
bağlantı kurulabilir ki (Page Mapping), page'ler mantıksal olarak devamlılık özelliğini
koruyabilir. Ancak blok'larda devamlılık özelliğinin aranması gerekmez.
Page
Page-Mapping
Blok
Adresleme alanındaki page'lerin fiziksel alandaki blok'lara yansıtılması
(Mapping) için her page'e iliĢkin ayrı bir registerin bulundurulması gerekmekte veya
belleğin belirli bir bölümü bu amaçla ayrılmalıdır. Bu registerlere page-map-registers
(ġekil-41), bellek bölümüne page-map-tables adı verilmektedir.
Ana Bellek
X
X
0
0
a
1
1
Sayfa 2 PMR
2
Sayfa 0 PMR
i
3
j
k
Sayfa 1 PMR
a
Sayfa 3 PMR
ġekil-41. Page Map Register’leri
Þekil:41. Page-Map-Registerleri
Programlardaki her sayfa ana bellekte eĢit uzunlukta yer kapsadığı için, boĢ /
serbest konumların tutulma iĢlemi de kolaylaĢacaktır. (Örneğin her sayfa için bir bit
ayrılmıĢ bir dizi biçiminde).
Paging ile devamlılık sorunu, bir partisyonun tümüyle devamlı olmasından bir
sayafanın devamlı olması sorununa indirgenmiĢ olmaktadır. Dolayısıyla sayfa boyunun
seçimi, bu yöntemin baĢarısındaki önemli etmenlerden biridir. Sayfa boylarını çok
büyük tutarsak, ana belleği yerdeğiĢir bölümlerle yönetmedeki sakıncalar bu çözümde
de kendilerini gösterirler (Örneğin programın sayfa boyuna göre çok ufak olmasından
kaynaklanan bellek kaybı). Sayfa boyu çok küçük olduğunda, bellek kesimlerinin sayısı
artacağından page-map-register sayısı artacak ve dolayısıyla sistemin hızı düĢecek,
maliyet artacaktır. Sayfa boyunu saptarken; ana belleğin kapasitesini, üretilen amaç
92
programların ana bellek birimi oranı, kullanılan verilerin bu birimlere oranları gözetilir.
Günümüzdeki sistemlerde yaygın olarak kullanılan boyutlar 1K, 2K, 4K ve 8K byte
kapasitesindedir.
Sayfa boyunun uzunluğu 1K olduğu bir sistemde adresleme alanı ile fiziksel alan
arasındaki bağlar ġekil-42'de gösterilmiĢtir.
Page Blok
0
0
1000
2000
0
5
1
6
1000
2000
2518
3000
Ýþ-1
ĠĢ-1
0
518 Load 1,2108
Sayfa-0 1000
Sayfa-1 2000
2108
ĠĢletim sistemi
sist.
Ýþletim
LOAD 1,2108
Boþ
BoĢ
0
2
4000
1
4
5000
2
7
6000
ĠĢ-2, Sayfa 1
Ýþ-2, sayfa-1
ĠĢ-1, Sayfa 0
Ýþ-1, sayfa-0
ĠĢ-1, Sayfa 1
Ýþ-1,
sayfa-1
015571
7000
7108
8000
Sayfa-2 3000
Ýþ-2
ĠĢ-2
015571
0
9000
8
Ýþ-3
ĠĢ-3
Adres Sahası
Adres Sayasý
ĠĢ-2, sayfa-2
Sayfa 2
Ýþ-2,
ĠĢ-3, sayfa-0
Sayfa 0
Ýþ-3,
0
1000
Ýþ-2,
sayfa-0
ĠĢ-2, Sayfa
0
Boþ
BoĢ
10000
Page-Map-Tables
Gerçek Bellek
ġekil-42. Adresleme Alanı Ġle Fiziksel Alan ĠliĢkisi
Þekil:42. Adresleme alaný ile Fiziksel alan liþkisi
ġekil-42'de gösterilen paging tekniğini uygulayan bilgisayar sistemlerine örnek
olarak XDS 940, XDS Sigma 7 ve CDC 3300 sistemleri verilebilir.
Bellek yönetiminin karĢılaması gereken dört iĢlevi vardır;
1) Ana belleğin durumunun iki ayrı tür tablo ile izlenmesi;
a) Her iĢ için adres alanı-bellek iliĢkisini kuracak registerlerin
düzenlenmesi.
b) Tüm bellekteki serbest-boĢ alanların belirlenmesi.
2) Ana belleğin kime atanacağını saptamak (ĠĢ yönetimi içinde çözülür.)
3) BoĢ sayfaları seçilen iĢe atamak üzere gerekli düzenlemeleri yapmak.
4) ĠĢ bitiminde kullanılan alanların serbest bırakılması.
Donanım Desteği
Programların iĢletiminde adres alanı-fiziksel adres arasındaki geçiĢ ya özel
amaçlı registerler (page-map-register) ya da ana bellekte bu iĢ için tutulan tablolarda
gerçekleĢtirilir.
Özel amaçlı register kullanımı pahalı bir yaklaĢımdır. Ana belleği adreslemek
üzere, her iĢe (Bellek büyüklüğü/ Sayfa büyüklüğü) kadar register ayırmak gerekir. ĠĢ
93
aliyetinin artması sistemin maliyetini doğrudan artıran etken olmaktadır. Bu nedenle
çoğu sistemlerde bu registerlerin adedi düĢürülür (20-25 tane) ve herhangi bir anda
sadece bir iĢin aktif olduğu gerçeği göz önünde tutularak kullanıcılar arasında paylaĢımlı
olarak kullanılırlar. Sistemde her yeni görev AĠB'ni kullanmak için anahtarlandığında bu
registerlerin de yeni adres sahası ile günlenmesi gerekir (ġekil-43). Örneğin XDS 940
serisi bilgisayarda bu yöntem uygulanmaktadır.
AĠB Taban Register Kümesi
ĠĢ-2Ýþ-2
0
ĠĢletim Sistemi
ĠĢ-4
AÝB taban register kümesi
ANA BELLEK
Ýþ-4
ĠĢ-4 : 0
Ý.S.
0
ĠĢ-4 : Ýþ-4:0
1
1
1
Ýþ-4:1
ĠĢ-5 : 0
2
Ýþ-5:0
ĠĢ-2 : 0
Ýþ-2:0
ĠĢ-5
AÝB'ye
atanmýþ iþ
ĠĢ-2 :Ýþ-2:1
1
Ýþ-5
0
Ýþ-2:2
ĠĢ-2 : 2
AĠB’ye AtanmıĢ ĠĢ
Ýþ-5:1
1
ĠĢ-5 : 1
2
ĠĢ-5 : 2
3
ĠĢ-5 : 3
Ýþ-5:2
Ýþ-5:3
Ana Bellek
Þekil 43: Registerlerin
Günlenmesi
ġekil-43.
Register’lerin
Günlenmesi
Bu Ģekilde 25 tane registerin kullanıldığını varsayacak olursak, page uzunluğunun 4K
olduğu bir sistemde çalıĢtırılabilecek en büyük program 100 K olacaktır. Gerek daha
büyük adresleme alanları oluĢturmak gerekse registerlerin devreye giren her iĢ için
yeniden yüklenip registerlerdeki eski bilgilerin saklanması büyük zaman kaybına neden
olmaktadır. Bu sakıncayı önlemek üzere uygulanan çözüm, adresleri ana bellekte
tablolar (page-map-tables) biçiminde oluĢturmaktır. Page-map-tables kullanımını
açıklamak için IBM-370 serisi bilgisayarlarda kullanılan page-mapping veya Dynamic
Address Translation (DAT) tekniği incelenebilir (ġekil-44). Bu yaklaĢımda AĠB'ye
atanmıĢ iĢin adres tablosunun bellek konumunu belirlemek üzere yanlız bir taban
registerinin kullanımı yeterlidir (DAT registeri).
94
CPU
Efektif Adres
32 Bit
24 Bit
L 1,Offset ( Base,Index )
P
0
P
a
g
e
0
B
l
o
k
1
2
0
7 8
b
19 20
31
12 bit
Page-No
12 bit
Byte No
PMT (P )
b
7 8
19 20
31
3
Fiziksel Adres
N
o
N
o
4096
b-bytes
Page Map Table ( PMT )
Page-P
DATMekanizması
Mekanizmasý
DAT
Fiziksel Bellek
ġekil-44.
Address
Translation
Tekniği
Þekil : Dynamic
44. Dinamic
Address
Translation
Tekniði
IBM-370 makinalarında page uzunluğu 1K-2K veya 4K olabilmektedir. Yine
370 komut yapısı hatırlanacak olursa efektif adres 24 bit uzunluğundadır. DAT
mekanizması 24 bitlik efektif adresi otomatik olarak iki bölüme ayırmaktadır.
Bunlardan biri 8-19. bitler arasında yer alan 12 bitlik page numarasına, diğeri ise 20-31.
bitler arasında yer alan o page'deki offseti belirtmektedir. DAT mekanizmasının bir
bölümü olarak gösterilebilen Page-Map-Table efektif adresden elde edilen 12 bitlik page
numarasının bellekteki bir blok'a yansıtılmasını sağlamaktadır. Eğer page-map-table
bellekte tutuluyorsa, donanımın bu bilgilerin belleğin neresinde bulunduğunu bilmesi
95
gerekir. Yani PSW, CAW, CSW'de olduğu gibi bu bilgilerin sabit bir yerde tutulması
gerekir. Ancak böyle bir yaklaĢımla CPU nun bir iĢten diğer bir iĢe geçiĢinde PMT'nin
de yeniden düzenlenmesi gerekir. Bu nedenle 370 sistemlerinde PMT'ler belleğin
herhangi bir yerinde saklanabilir bir Ģekilde düzenlenmiĢlerdir ve PMT'lerin bulunduğu
yerde Page-Map-Table-Address-Register (PMTAR) adlı bir registerde tutulmaktadır. IĢ
değiĢiminde sadece PMTAR yı yeniden yüklemek gereklidir. Dolayısıyla CPU kontrolü
bir iĢten diğer bir iĢe geçtiğinde yapılacak iĢlem, yeni iĢin PMT'sini belirten adresin
PMTAR registerine yüklenmesi olmaktadır.
PMT içindeki bilgiler çeĢitli Ģekillerde düzenlenebilir. 370 sistemlerinde blok
sayısı 4096 olabileceğinden blok numarası için 12 bitlik bir alan gerekir, bu da 2 byte
veya half-word içine ġekil-45'teki gibi yerleĢtirilmektedir.
16 bit
Kullanýlmýyor
Kullanılmıyor
Blok No
12 bit
4 bit
ġekil-45. Blok Numarasının YerleĢimi
Þekil:45. Blok Numarasýnýn Yerleþimi
Page, Blok, PMT ve PMTAR arasındaki iliĢkiler ġekil-46’'da gösterilmiĢtir.
96
Page-Map-Table Adres register
Page-Map-TableAddress Register (PMTAR)
3
0
4160
5
6
Uzunluk
8
PMT
4K
Adres
Blok-0
+
4160 2
ĠĢl. Sist.
Ýþl.Sis.
4162 4
Blok-1
4164 7
8K
Blok-2
8710
(8192+518)
L 1,8108
Ýþ-2,P-0
ĠĢ-2,P-0
12 K
Blok-3
ÝÞ-2
PMT
16 K
Blok-4
Blok-4
ĠĢ-2,P-1
Ýþ-2,P-1
20 K
Blok-5
24 K
Blok-6
28 K
(4096x7+108) 28780
32 K
0
518
015571
Blok-7
Blok-7
ĠĢ-2,P-2
Ýþ-2,P-2
L 1,8108
Blok-8
36 K
4K
Blok-9
40 K
Fizikselbellek
Bellek
Fiziksel
8K
8108
015571
12 K
Ýþ-2Adresleme
AdreslemeAlanı
alaný
ĠĢ-2
ġekil-46. Page, Blok, PMT ve PMTAR Arasındaki ĠliĢkiler.
Þekil: 46. Page,Blok, PMT ve PMTAR arasýndaki iliþkiler
IBM-370 sistemlerinde bir iĢin adresleme alanı 16 Mbyte (4906 * 4K) olabilir.
Eğer her iĢ için PMT 4096 giriĢli bir liste olacak olursa, her iĢ için PMT 'ın 8192 byte
uzunluğunda olması gerekir. bu sorunu çözebilmek için de PMT'larının değiĢik
uzunluklarda, yani gerektiği kadar uzunlukta, yapılması öngörülmüĢ ve PMT 'nin
97
uzunluğu PMTAR'nin bir bölümünde belirtilmiĢtir. Bu uzunluk parametresi bir yerde
sınırlama registeri Ģeklinde görev yapmakta ve bağlı olduğu iĢin adresleme alanını
sınırlamaktadır.
Eğer DAT iĢlemi bellekte oluĢturulmuĢ PMT’ler ile gerçekleĢtirilecek olursa bu
sistemin % 50 hızı ile çalıĢmasına neden olur. BaĢka bir deyiĢle DAT % 100 yük getirir.
Çünki PMT'ler bellekte saklanacak olursa her bellek eriĢimi söz konusu olduğunda önce
PMT'ye daha sonra da bellekte istenilen yere eriĢmek için iki bellek eriĢimi
gerekecektir. CPU'nun yavaĢlamasına neden olan bu sorunun gidermek amacıyla, PMT
'lerin ve page-map-registerlerinin beraber kullanılmasından Hybrit Page-Mat-Table'ları
ortaya çıkmıĢtır.
Bu amaçla örneğin 16 tane özel amaçlı PMR bulundurulmakta ve bunlar PMT
'lerin
bir kısmının tuttuğu bilgileri içermektedirler. PMR'lerin PMT 'lerden
yüklenmeleri otomatik olarak yapılmakta, ne iĢletim sistemi ne de iĢler PMR-PMT
iliĢkisinin farkında olmamaktadır. Bu teknikle yük %100’den %10’un altına
düĢmektedir. PMR’ler ve bunlarla ilgili donanıma Associative Memory veya Table
Look-Aside Buffer adı verilmektedir.
Yazılım Desteği
ĠĢletim sistemi temel olarak 3 ayrı tablo üzerinde iĢlem yaparak Paged Bellek
Yönetimi’ni gerçekleĢtirmektedir. Bunlar;
1) Job Table (ĠĢ Tanım Tablosu)
Sistemde çalıĢan iĢlerin tanımlandığı bu tabloda her iĢin uzunluğu, PMT'sinin
adresi ve statü bilgiler tutulmaktadır.
2)Memory Block Table (Bellek Öbek Tablosu)
Her iĢin adres sahasını belirleyen bilgiler (bellekteki her blok için statü bilgileri)
tutmaktadır.
3)Page Map Table
Yazılım açısından tabloların kullanımı ġekil-47'de gösterilmiĢtir.
98
ĠĢ No
Ýþ
No
ĠĢ Uzunluğu
Ýþ
Uzunluðu PMT Adresi
Statü
1
8K
3600
Atanmýþ
AtanmıĢ
2
12 K
4160
Atanmýþ
AtanmıĢ
3
4K
3820
Atanmýþ
AtanmıĢ
4
Page No
Blok No
0(3600)
5
1(3602)
6
Boþ
Page No
Blok No
0(4160)
Ýþ-1PMT
PMT
ĠĢ-1
Job Table
2
1(4162)
4
2(4164)
7
Page No Blok No
0(3820)
8
ĠĢ-3
Ýþ-3PMT
PMT
Ýþ-2PMT
PMT
ĠĢ-2
Page Map Tables
Blok No
Statü
0
Ý.S.
Ġ.S.
1
Ý.S.
Ġ.S.
Ýþ-2
ĠĢ-2
Boþ
BoĢ
Ýþ-2
ĠĢ-2
Ýþ-1
ĠĢ-1
Ýþ-1
ĠĢ-1
Ýþ-2
ĠĢ-2
Ýþ-3
2
3
4
5
6
7
8
9
Memory Blok Table
Boþ
ĠĢ-3
BoĢ
ġekil-47. Paged Bellek Yönetimi Tabloları
Þekil:47. Paged Bellek Yönetimi Tablolarý
99
Adres Sahası Atama Algoritması
λk kadar adres
sahası istemi
Gereksenen blok sayısı
N = λK / 4K
H
N tane blok
var mı?
ġu anda adres
sahası atanamaz
E
Job Table’da boĢ
sahaları bul, statülerini
değiĢtir.
PMT’i N blok için
düzenle.
MBT’da tarama yaparak
N bellek blok ataması
yap.
D Ö N
Adres Sahalarının Kesişmesi
ġimdiye değin tanımlanan dinamik bellek düzenleme yöntemlerinde iĢlerin adres
sahalarının birbirinden bağımsız oldukları varsayılmıĢtır. Bu nedenle bunları karĢılayan
fiziksel konumlar da ana bellekte ayrı ayrı atanmıĢtır.
Her iĢin eriĢim alanının bir diğeriyle kesiĢmesi bu iĢler arasında doğal bir
koruma mekanizması oluĢturur. Ancak ana bellekteki bazı öğelerin (Program, veriler)
ortak kullanımı arzulanan bir seçenektir. Adres alanlarında çakıĢmanun iĢletim sistemi
ve iĢler arasında gerçekleĢtirilmesi çoğu kez yeterli bir esnekliktir. Adres alanlarını
100
çakıĢtırmada kullanılabilecek bir yöntem de her iĢteki adres alanının belirli kesiminin
(Örneğin ilk sayfa) ortak olarak tanımlara ayrılmasıdır (ġekil-48).
Her
ortak
kullandýðý
Herikiikiiþin
iĢin
kullandığı
sayısayfa
Yeniden
yazýlýr
tutulmalý
Yenidengirilir
girilir
yazılım
DAT 1 MPT
tutulmalı
Ġ.S
DAT1 (MPT) . Ý-S
Program A
DAT2
iliĢkin bilgi
Program B
eklenecek
Program B
0
1
2
A
3
Eriþim haklarýna iliþkin
EriĢim
haklarına
Bilgi
eklenecek
B
4
Ýþ-B
ĠĢ-B
EriĢim
Alanı
Eriþim Alaný
A
Ýþ-A
ĠĢ-A
EriĢim
EriþimAlanı
Alaný
A
B
A
~
~
ġekil-48. Adres Alanlarının KesiĢmesi.
Þekil:48. Adres alanlarýnýn kesiþmesi
Sistemde ortak kullanılan sayfaların korunması, paylaĢımın verdiği genel
sorundur. DAT (MPT)'larda yada özel taban registerlerinde kullanılan eriĢim haklarını
belirleyen ve kısıtlayan göstergelere yer verilir.(oku/yaz, salt oku, iĢletim vb).
Avantajları
1) Ana belleğin parçalanmasını önler.
2) Belleği eĢit parçalara böldüğü için diğer yöntemlere göre atama yöntemi
yalındır.
3) Belleğin daha iyi kullanımını sağladığı için çok iĢ düzeninde baĢarı düzeyi
artar.
Dezavantajları
1) Komut iĢletim süresini ve kullanılan ek donanım nedeniyle sistem fiyatını
arttırır.
2) IĢletim sisteminde kullanılan veri yapılarının karmaĢıklığı artar.
3) Program boylarının sayfa kapasitesinin tam bir katsayısı olmaması sebebiyle
son sayfalarda "kırpıntı" diye adlandırdığımız boĢ alanlar oluĢur.
4) Ana belleğe yeni bir iĢ yüklendiğinde yeterli boĢ sayfaların bulunmaması bu
iĢlemi engeller, böylece bazı sayfalar boĢ olmalarına karĢın kullanılmadan dururlar.
101
10.2.2. Görüntü Ana Bellek Yönetimi
Gerçek ana bellek yönetimi olarak tanımladığımız bellek düzenleme
yöntemlerinde iĢler, gereksendikçe tüm bellek alanlary atanana değin çakıĢmamaktadır.
Bu yapı içinde çalıĢmak için bekleyen iĢlerin olmasına karĢın ana belleğin bir kesiminin
kullanılmaması olası bir durumdur. Bu olgunun yanı sıra her iĢe ayrılan eriĢim alanı,
programlar ve kullanıldıkları veriler üzerine kapasite kısıtlamaları getirmektedir. Sözü
edilen yöntemlerde bir iĢin adres alanı ana belleğin kapasitesi ile sınırlıdır. Ancak çok iĢ
düzeni nedeniyle bu alan gerçekte sistem kapasitesinin çok altında tutulur. Günümüzde
ana bellek teknolojisinin geliĢmesiyle bu kaynakta ekonomik nedenlerle sınırlamalar
giderek azalmaktadır. Yakın tarihlere kadar ana belleğin sistem değerinin önemli oranını
tutması nedeniyle bu kaynak üzerinde yoğun olarak çaba harcanmıĢ ve birçok
düzenleme yöntemi geliĢtirilmiĢtir. Bunlardan ana belleği en ekonomik olarak
kullananları "Görüntü Bellek Düzenleme Yöntemleri" adı altında toplanmaktadır.
Görüntü ana bellek düzeni bir iĢin adres alanına iĢe atanabilecek fiziksel bellek
kesimini açma olanağını sağlayan yöntem olarak tanımlanabilir. BaĢka bir deyiĢle bir
programın iĢletimi için tümünün ana bellekte bulunması gerekmemektedir.
Zaman içinde bir programın çalıĢmasını izlediğimizde iĢletiminde gereksenen
komut veri kümesinin belirli sınırları içinde kalması olasılığının büyük olduğunu
görürüz. Buna göre bir programın çalıĢabilmesi için bazı kesimlerinin ana bellekte
bulunması yeterlidir. Ancak her an gereksinim bulunup da ana bellekte bulunmayan
öğelere eriĢilebileceği sorununu çözmek gerekmektedir.
Görüntü bellek düzenlemede yaygın olarak uygulanan teknikler Demand-Paged,
Segmented and Demand-Paged olarak sıralanabilir.
10.2.2.1. Demand-Paged (Ġstenebilir-Sayfalı) Bellek Yönetimi
Buraya kadar sözünü ettiğimiz bellek yönetimi teknikleriyle bir programın
adresleme alanının tümü fiziksel alana yerleĢtirilmedikçe o programın çalıĢtırılması söz
konusu olamıyordu. Demand-Paged bellek yönetim tekniğinin temelini oluĢturan
kavram ise bir programa iliĢkin adresleme alanının tümüyle fiziksel alana yerleĢtirilmesi
zorunluluğunun olmamasıdır (ġekil-49).
Bu yöntemde programlar ve veriler sayfalama yönteminde olduğu gibi
derleyici/çeviriciler aracılığı ile eĢit uzunlukta sayfalara bölünürler. ĠĢletimi istenen her
iĢe gereksediği tüm bellek alanını karĢılayacak kadar ikincil bellek atanır. Öğelere
eriĢim sayfalama yönteminde olduğu gibi registerler yada dat aracılığı ile gerçekleĢtirilir.
Ancak bu yapılarda eriĢilen sayfanın ana bellekte bulunup bulunmadığını belirleyen bir
de belirteç yer alır. Adresleme sürecinde eriĢilmek istenen sayfa ana bellekte değilse bu
gösterge aracılığı ile süreci durdurmak üzere bir kesilme üretilir. ĠĢletim sistemi
kesilmenin nedenini saptayarak gereksenen sayfanın ana belleğe taĢınmasına
çalıĢacaktır. Sayfa ana belleğe getirildiğinde iĢletimi kesilen komut yeniden baĢlatılır ve
bu süreç iĢ sonuna değin sürdürülür.
102
ĠĢ-1
Ýþ-1
0
Page Statü Blok
0
0
1
1K
2K
E
E
5
6
ÝÞL.
ĠġL.
1K
SĠST.
SÝS.
ĠĢ-2
2K
Ýþ-2
0
1K
2K
0
1
2
3K
E
E
E
2
4
7
3K
L 1,1120
3100
A 1,2410
3401
006802
9210
4K
Ýþ-3
ĠĢ-3
0
1K
0
E
8
5K
ĠĢ-4
Ýþ-4
0
6K
100 L 1,1120
104 A 1,2410
1K
1120
006802
0
E
3
7K
1
2
3
E
H
H
9
-
8K
2K
2410
3K
006251
9K
10K
4K
ġekil-49. Demand-Paged
Þekil:49. Demond-Paged
bellek yönetimi Bellek Yönetimi
ġekil-49'da belirtildiği gibi ĠĢ-4'ün adresleme alanı tümüyle fiziksel alana
yansıtılmamıĢtır. Ancak ĠĢ-4 sadece 0 ve 1. page'lerdeki bilgilere eriĢiyorsa çalıĢmasında
herhangi bir aksaklık olmayacaktır.
Bu durumda iki sorun söz konusudur:
1) Bir program (iĢ) fiziksel alana yansıtılmamıĢ bir page'deki bilgilere eriĢmek
isterse ne olacaktır ?.
103
2) Hangi page'lerin bellekte tutulması gerektiğinde nasıl karar verilecektir.
ġekil-49’da belirtildiği gibi ĠĢ-4'ün 104 adresindeki 1,2410 gibi bir komutla
2410 adresindeki bir bilgiye eriĢmek isteniyor ancak bu bilginin bulunduğu page
bellekte değildir. Bu gibi durumlarda hangi bilgilerin bellekte olduğunu belirlemek için
"page map table" ında " 1 bitlik bir statü bilgisi tutulmaktadır.
Statü bit'i;
Hayır-0 (Page bellekte değil)
Evet-1 (Page bellekte)
Bellekte bulunmayan bir page'e eriĢmek istendiğinde page mapping donanımı,
statüsü (0) olan bu page için bir "page- interrupt" ı oluĢturur. Bu interrupt'ın servisini
yapan iĢletim sistemi istenilen page'i belleğe yerleĢtirir ve page map table'da gereken
düzenlemeleri yapar.
ĠĢte page'lerin gerektiğinde belleğe yüklenmesi nedeniyle bu tekniğe
"Demand-Paged" bellek yönetim tekniği adı verilmektedir.
Sisteme girilmesi istenilen bir iĢ (Program) geldiğinde önce bu iĢin page'i
yüklenir. Diğerleri ise istek (Demand) üzerine gerektiğinde belleğe getirilir. Böylece o
anda kullanılmayacak olan page'lerin belleği iĢgal etmeleri engellenir.
Bir "Page Interrupt" oluĢtuğunda istenilen page'in nereden yükleneceği sorusu
akla gelmektedir. Aslında sisteme girilen bir iĢin adresleme alanı tümüyle ikincil-bellek
adını verdiğimiz manyetik disk veya durum gibi saklama organlarında tutulmaktadır.
Söz konusu iĢ için bir page istenildiğinde ikincil bellekten alınıp ana belleğe
yerleĢtirilmektedir.
Demand-Paged tekniği, bellek yönetimi açısından etkin bir teknik olmasına
karĢın bazı sorunları da vardır. Örneğin ġekil-49 incelenecek olursa; A 1,2410
komutunu iĢleyebilmek için ĠĢ-4 'ün 2. page'ini yüklemek gereklidir. Ancak bellekteki
bütün bloklar kullanıldığından yeni gelen page nereye yerleĢtirilecektir?. Ana bellekteki
bütün bloklar kullanıluyorsa, yeni bir page'i belleğe yerleĢtirmek için bellekteki
bloklardan birisinin boĢaltılması gereklidir. Bunun için boĢaltılacak bloktaki bilgilerin
ikincil belleğe kopya edilmesi gerekmektedir. Bu iĢleme page swapping, page removal,
page replacement veya page turning adı verilmektedir.
Bir diğer soru ise, hangi blokun boĢaltılabileceği hakkında nasıl karar verilmelidir?
Bu konu ile ilgili birçok çalıĢma yapılmıĢ ve çeĢitli page-replacement algoritmalarıı
geliĢtirilmiĢtir. Bunlardan en önemli olanlarından ileride söz edilecektir.
Bu teknikte diğer bir sorun da, ana bellekten ikincil belleğe kopya edilen page'in
tekrar belleğe getirilmesi olayıdır. Bu durum genellikle çok küçük ana belleği bulunan
sistemlerde görülen ve Thrashing adı verilen bir olaydır. Thrashing konusu da
günümüze kadar gelen bir araĢtırma konusudur ve bununla ilgili halen devam etmekte
olan bazı çalıĢmalar bulunmaktadır (Denning, Ramdell, Coffman).
104
Demand-Paging bellek yönetim tekniğini uygulayan sistemlere örnek olarak VS-1,
VS-2, VM-370, Honeywell 6180'de Multics ve Univac 70/46'da VMOS iĢletim
sistemleri verilebilir.
Donanım Desteği
Sayfala yöntemine ek olarak, adres çözümleme sürecinde donanımın, eriĢimi
istenen sayfanın bellekte bulunup bulunmadığının denetlemesi gerekir. Donanımda
adresleme sürecini durdurmak üzere ek bir kesilmenin öngörülmesi gerekir.
ĠĢletim sistemi birçok durumda öğelerin gerçek adresleriyle çalıĢmak zorundadır.
Örneğin G/Ç kanallarına iletilecek veri alanı adreslerinin, ana bellekteki fiziksel bir
konumu doğrudan göstermesi istenir. Bu gibi sorunları karĢılamak üzere donanımda bir
öğenin gerçek adresini saptayan ek bir komut (load real address) ve daha özel
uygulamalar için de (örneğin yükleyici yordamında) sistemin gerçek adreslerle
çalıĢabilecek ek olanaklar gereklidir.
Donanım açısından "demand-paged" bellek yönetimi "paged" bellek yönetiminde
sözünü ettiğimiz donanıma (PMT, PMTAR, PMR) ek olarak 3 donanım elemanı daha
gerektirir. Bunlar ;
1) Page'lerin ana bellekte veya ikincil bellekte bulunduğunu göstermek amacıyla
kullanılan ve "Page Map Table" ın içinde tutulan 1 bitlik statü bilgisi,
2) Bellekte olmayan bir bilgi istenildiğinde "interrupt" veri kontrolü iĢletim
sistemine aktaracak bir mekanizma,
3) Her page'in kullanımıyla ilgili bilgileri tutup "Page-removal" iĢleminde iĢletim
sisteminin hangi page'in (blokun) boĢaltılması gerektiği üzerine karar vermesinde
yardımcı olacak bir mekanizmadır.
Bu donanım elemanlarının nasıl sağlandığını açıklamak için IBM 370 sisteminin
"Exteded Control Mode" unda yani DAT'’ın çalıĢtırıldığı ortam incelenebilir. DAT
mekanizmasının çalıĢmasını anlatırken belirttiğimiz gibi blok numaraları Page Map
Table içinde 2 baytlık yani 16 bitlik bir sahayı kaplayacak bir Ģekilde tutulmaktaydı.
Ancak bu 16 bitlik bu sahanın sadece 12 bitlik bir kısmı en fazla 4096 bloğu belirtmek
için yeterli olduğundan 12.bit pozisyonu page statüsünü belirlemek için kullanılmaktadır
(ġekil-50).
1 bit
12 bit
I
0
11 12 13
ġekil-50.Blok
Bloknumarasý
Numarası
Þekil:50.
105
15
Eğer söz konusu page bellekte değilse I=1 dir ve bu page 2’ye eriĢilmek istenirse
iĢletim sistemi "page interrupt" ının oluĢmasını sağlar. Page Exception veya page Fault
adı verilen bu interrupt oluĢtuğunda (Interrupt code=17) programın (iĢin) eriĢmek
istediği yerin adresi ana bellekte 144 adresinde saklanır. ĠĢletim sistemi 144 adresindeki
bilgiyi kullanarak gereken page'i belleğe yükler.
Diğer yandan 370 sistemlerde her blok için 2 bitlik bilgi daha tutulmaktadır.
Bunlardan biri referance bit olup, o bloktaki bilgilere eriĢilmek istenildiğinde (LOAD,
STORE gibi) 1 değerini almaktadır. Diğeri ise change bit olup, o bloktaki herhangi bir
bilginin üzerinde değiĢiklik yapıldığında (STORE gibi) 1 değerini almaktadìr. Referance
bit ve change bit bazì sistemlerde (Honeywell 6180'de olduğu gibi) Page Map Table
içinde tutulmaktadır.
IBM 370 sistemlerde ise bu 2 bitlik bilgi belleğin her 2 K'sı için kullanılan özel
amaçlı LOCK registerlerinde tutulmaktadır. ĠĢletim sistemi set storage key privileged
komutunu kullarak bu bitlerin değerlerini değiĢtirebilmektedir.
Yazılım Desteği
Demand Paged Bellek Yönetimi’nde adresleme alanının (page'lerin) ana bellek ile
ikincil bellek arasında transfer edilmeleri söz konusu olduğundan pagelerin ikincil
bellekte nerede bulunduklarını belirtecek bilgilerin tutulması gerekmektedir. Aslında bu
konu iĢletim sistemlerinin "bilgi yönetimi" ile ilgili bölümüne girmektedir, Ģimdilik her
page'in ikincil bellekte bir adresi olduğu varsayabilir ve bu adrese page file adresi adını
verebiliriz. Mantıksal olarak page file adresi de page map table içine alınabilir (ġekil51).
32 bit
Blok no
0
I
Page-File-Adres
11 12 13
15 16
31
16 bit
ġekil-51. Blok-no, Page-File-Adres ĠliĢkisi
Þekil:51. Blok-No, Page-adres iliþkisi
Page Map Table'da bulunan bilgiler direkt olarak donanımla değildir (DAT),
page-file-adres ise yazılım yoluyla iĢlenebilir bilgilerdir. Bu nedenle page-file-adres
bilgileri genellikle file-map-table (FMT) adı verilen ayrı bir yerde tutulmaktadır.
File-Map-Table, Page-Map-Table ve Memory-Blok-Table arasındaki iliĢkiler
ġekil-52’de gösterilmiĢtir.
106
Blok no
0
1
2
3
4
5
6
7
8
9
Statü
Ýþl.Sis
Ýþl.Sis
Ýþ-2, P-0
Boþ
Ýþ-2, P-1
Ýþ-1, P-0
Ýþ-1, P-1
Boþ
Ýþ-3, P-0
Boþ
Memory Blok Table
Referance
ĠĢl. Sist.
ĠĢl. Sist.
Change
Page-Map-Table
Adres register
0
ĠĢ-2, P-0
ĠĢl. Sist.
ÝÞL.SÝS.
BoĢ
4K
ĠĢ-2, P-1 Blok Table"
"Memory
ĠĢl. Sist.
ÝÞL.SÝS.
ĠĢ-1, P-0
ĠĢ-1, P-1
R C
R C
8K
L 1,8300
BoĢ
12K
ĠĢ-3, P-0
BoĢ
16K
Page-Map-Table
File-Map-Table
Page
File-Map-Table
(Page-File-Adres)
Page Blok
0
2
1
4
0
1
2
2
-
I
0
0
20K
24K
1
28K
32K
Ġkincil Bellek
36K
Ýkincil bellek
ĠĢ-2
40K
Ýþ-2
0
518 L 1,8300
P0
4K
P1
8K
8300 015571
P2
12K
ġekil-52.
File-Map-Table,
Page-Map-Table,
Þekil:52.
File-Map-Table,
Page-map-table, Memory
blok table iliþkisi
Memory-Blok-Table ĠliĢkisi
Adresleme Sürecinin İncelenmesi
Bu yöntemde adresleme süreci donanım ve yazılımın tümlediği bir yapıyı
kullanır. EriĢilmek istenen sayfanın bellekte bulunmadığı durumlarda adresleme
sürecinin kesilmesi belirsiz bir süre sonunda çözümlenecek bir aramaya girilmesinden
kaynaklanır. Bu aramayı adım adım incelediğimizde çözümleyebileceğimiz sorunları
Ģöyle sıralayabiliriz;
a) Bellekte atanacak boĢ bir sayfa bulma,
b) BoĢ yer yoksa, yer açmak üzere bir seçim yapmak,
107
c) Ana bellekten atılacak sayfa ikincil bellekteki kopyasından farklı ise, yani
günlenmiĢ ise (içindeki veriler değiĢtirilmiĢ ise) bu sayfayı ikincil bellekteki yerine
yazmak,
d) EriĢilmek istenen sayfayı ana belleğe yüklemek,
e) ĠĢletimi kesilen komutu yeniden baĢlatmak.
Bu iĢlemleri gerçekleĢtirirken ek bellek sayfalarına gereksinim duyabileceğimiz
düĢünülürs, yöntemin yalın görünümüne karĢın iĢletim esnasında karmaĢık yapılar
oluĢturabileceği gözlenebilir.
Yukarıda saydığımız adımların gerçekleĢtirmek için kullanılan veri yapılarının
da ek bilgileri içermesi gerekir. Örneğin hangi sayfanın bellekten çıkarılacağına karar
vermek için sayfanın kullanım durumunu yansıtan bir göstergeye gereksinim vardır.
Kullanılan algoritmalara göre (FIFO, LRU,...) bu göstergeler karmaĢık bir yapıya
doğru gidebilirler. Ana bellekteki sayfaların kullanmada yada serbest olduğunu gösteren
belirteçlerin yanısıra, sayfanın durumunu saptayan ek belirteçlere gereksinim duyulur.
Ana bellekle ikincil bellek arasında aktarılmakta olan bir sayfayı yeniden
seçmemek için "aktarılmakta" olduğunu tutmak gerekir. Ana bellekte kullanılan bazı
sayfalar da boĢaltılamaz durumdadır. Özellikle G/Ç ların yapıldığı alanların yerini
değiĢtirmek çok sakıncalı durumlar yaratabilir, bunların da "saltık (transit)" konum
olarak gösterilmesi gereklidir. Ana belleği boĢaltmak üzere seçilen bir sayfanın her
zaman ikincil belleğe yazılması gereksiz bir yük olabilir. Bu sayfanın ikincil bellekteki
kopyasıyla uyumlu olması bu taĢıma iĢlemini gereksiz kılar. Durumu saptamak üzere
eriĢim, donanımca günlenen "değiĢtirilmiĢ sayfa" göstergesi kullanılır.
Demand-Paged bellek yönetiminin en önemli özelliklerinden birisi bellek atama
iĢleminin dinamik olarak yani "execution" sırasında yapılmasıdır. Bu nedenle bu bellek
yönetiminin uygulandığı sistemlerde bellek yönetim donanımı (DAT gibi) ile bellek
yönetimi yazılımı arasında çok sıkı bir bağ bulunmaktadır. Bellek yönetim yazılımını
page interrupt ' ları açısından ele alacak olursak, bu bağın nasıl oluĢtuğu ġekil 53'te
gösterilmiĢtir.
108
Komut iþlenmesine
ĠĢlenmesine
Komut
D
O
N
Baþla
BaĢla
Data
DataAdresini
AdresiniOluĢtur
Oluþtur
A
N
Page No'sunu bul
Bir sonraki komutu ele al
I
M
Page Bellekte mi ?
H
E
Adreslemeyiyap
yapve
Adreslemeyi
ve komutu
Komutu
ÝþleiĢle
Page Interrupt
A
Page Interrupt
109
A
BoĢBoþ
blokBlok
var Var
mı ?mý ?
Y
BoĢaltılacak bir blok
Boþaltýlacak
bir blok seç
seç
H
E
A
Blok
Page Tabloları’nı
düzenle
Blok-Page
Tablolarýný
Düzenle
Z
H
I
BloktadeğiĢiklik
Deðiþiklikvar
varmı?
mý ?
OOblokta
E
L
Bloðu
ikincil
belleðe
kopyala
Bloğu
ikincil
belleğe
kopyala
I
M
Ýstenen
Pagebul
' in (Loc
No 'sunu
Ġstenen page’in
no’sunu
144)
Bul (Loc 144)
File Map Table ' dan
Page Adresini Bul
Page ' i Belleðe Getir
Page’i belleğe getir
Blok/Page
Tablolarýný
düzenle
Blok/Page
Tabloları’nı
Düzenle
Kesintiye
KesintiyeUðrayan
UğrayanKomutu
Komutu ĠĢlemeye BaĢla
Ýþlemeye Baþla
Þekil: 53.Demand-Paged
Demond Paged
BellekYönetiminde
YönetimindeYazılım-Donanım
Yazýlým-Donaným
Ýliþkisi
ġekil-53.
Bellek
ĠliĢkisi
Yöntemin Tartışılması
Demand-Paged yönetimi ana bellekte iĢletimin her anında yalnızca kullanılan
program sayfasını ve gerekirse bir veri sayfasının bulunmasını yeterli gördüğünden, ana
belleğin yönetimini çok etkinleĢtiren bir yaklaĢım olarak yaygın bir biçimde
uygulanmaktadır. Ancak her yöntemde olduğu gibi getirdiği katkılar bir takım yan
sakıncalarla dengelenmektedir.
110
Avantajlar
1) Görüntü bellek uygulaması nedeniyle iĢlere sınırsız ana bellek olanağı
sağlaması,
2) Çok iĢ düzeninde iĢ sayısını sınırsız olarak arttırmak,
3) Sistem kaynakk kullanımını arttırmak.
Dezavantajlar
1) Sistemde izlenip tutulacak veri sayısını arttırır.
2) Bulunmayan sayfa kesilmesini iĢleyecek ek yazılım gerektirir.
3) Komut iĢletim süresi artar.
4) Adresleme sürecinin yazılım kesiminde de "bulunmayan sayfa" kesilmeleri
oluĢabileceği gözönünde tutulursa, komut iĢletiĢm süresi belirsizleĢir ya da bir sayfayı
boĢaltmak için ek sayfa gerektiğinde sistemde kilitlenmeler oluĢabilir.
5) BoĢaltılacak sayfayı seçecek yordam çok karmaĢık bir algoritma olabilmesine
karĢın baĢarısı sınırlı olabilir.
6) Ana bellekte yer bulunmadığında, eksik sayfa uyarılarının artması sistemin
baĢarısını düĢürmeye baĢlar. Bu durumun son aĢaması, yeni bir sayfayı yüklemek için
yükleme istemini yapan program kesimini ana bellekten atmaktadır.
7) ĠĢletim sisteminin eksik sayfa kesilmeleriyle yoğun bir Ģekilde uğraĢmaya
baĢlamasına "TRASHING" adı verilir. Trashing'de çalıĢan bir sistemde ana bellekte
yeterli yer açıp tıkanan iĢleri sonuçlandırmak bellek yöneticisinin en karmaĢık görevidir
(ġekil-54).
AĠB’nin
AÝB'nin
iĢlere
iþlere
atanması
Kesilme
Sayýsý
Sayısı
atanmasý
Trashing
Ýþ Sayýsý
Optimum
ĠĢ Sayısı
Kullaným
Kullanım
ġekil-54.
Þekil : 54.Trashing
Trashing
Sayfa Yükleme Politikası
1) Sayfaları kullanımdan önce yükleme (Prepaging).
2) Ġstem üzerine yükleme.
3- a) Programların iĢletimdeki davranıĢlarını öngörme zorluğu.
111
Ana Bellek
Kapasitesi
b) YanlıĢ sayfayı yüklemenin getirdiği ek kayıp.
Sayfa Atama Yöntemleri
Gerekli sayfaların bellekten atılmaması gerekir.
1) Rastgele
2) FIFO (First In First Out)
Bellekte en çok kalmıĢ sayfayı çıkarma
- Kalıntılar temizlenir
- En çok kalan gereksiz.
3) LRU (Last Recently Unused = En uzun süredir kullanılmayan)
- En uygun yöntem.
- Donanım da devreye girerek pahalı çözüme yol açması.
4) Önceden tanımlanmıĢ öncelikler
- Öncelikli iĢlerin diğerlerini tıkamaması
5) Optimal
- En uzun zaman kullanılmayacak olan
6) KarıĢık yöntemler
Working Set
Working set, bir programın t zaman aralığında çalıĢmak için gereksediği sayfa
sayısısır (Herhangi bir görev için kabul edilir bir zaman aralığı içinde bulunmayan ya da
eksik sayfa uyarısı üretmeyen sayfa sayısıdır). Zaman aralığını programın iĢletim süresi
olarak tanımladığımızda "working set" program boyuna doğru yaklaĢır, tam eĢitlik
programda kullanılmayan kesimler nedeniyle sağlanmayabilir.
Ġstem üzerine sayfalama yapan sistemlerde ana bellek yöneticisinin en uygun
yöntemi uygulamak üzere dayanabileceği en sağlıklı parametre, programların working
set'leridir. Ancak programların dinamik davranıĢları iĢletimden önce kesinlikle
kestirilemez ve bu davranıĢ değiĢik uygulamalarda değiĢebilir.
ĠĢletim sistemlerinde baĢarı ölçümü yapanlar, gene de programların
davranıĢlarında belirgin bir yerellik olduğunu gözlemiĢlerdir. Bu yerel davranıĢ iki
sınıfta toplanabilir;
1) Zaman içinde yerellik: Son eriĢilen bir verinin yakın bir zamanda tekrar
eriĢilme özelliğidir. Programdaki döngüler ve sık kullanılan değiĢkenler alt
yordamlardan kaynaklanır.
2) YerleĢimde Yerellik : Programın bir konumundaki bir verinin yakınında
bulunan diğerlerinin kısa bir süre sonra eriĢilme özelliğidir. Komutların ardıĢık iĢletimi,
diziler, zincirler gibi doğrusal veri yapılarının kullanımı, ilk kullanılan değiĢkenlerin
program içinde bir araya konmasından kaynaklanır.
Ġstem üzerine sayfalamanın uygulandığı bir sistemde iĢletilen programlar ne
kadar yerel davranırlarsa sistemin baĢarı Ģansını o derece arttırırlar. BaĢka bir deyiĢle bir
112
görevin working set'i kabul edilir bir zaman aralığı içinde bellekte bulunmayan sayfa
uyarısını üretmeyen kesimidir.
e değiĢkeninin bir program içinde bellekte bulunmayan sayfa uyarısına yol açan
komut yüzdesi olduğunu varsayalım, p de ana bellekte bulunan sayfaların yüzdesini
göstersin. Bir iĢletimde bellek ulaĢımının dağılımının rastgele olduğu varsayılırsa e=1-p
dir. BaĢka bir deyiĢle herhangi bir bellek eriĢimini herhangi bir sayafaya yöneltilmesi
eĢit olasılıktadır.
e
Yerellik
Trashing
Rastgele
Optimal
P
Ancak yerellik kavramı gerçek eğrinin ilkinin altında olması gerektiğini
göstermektedir. Ancak bu çizim ana bellekte working set'i oluĢturan "en iyi p" sayfanın
bulunduğunu varsaymaktadır. Ayrıca en sık adreslenen sayfaların da hemen hemen her
zaman bellekte tutulduğu varsayılmıĢtır. Bu varsayımlar sayfa atama yönetemleri ile
doğrudan iliĢkilidir. Optimal atama algoritması bu varsayımları karĢılarken LRU tam
sağlanamaz.
Sayfalama Yöntemlerinde Davranış Anormallikleri
Trashing, iĢletimde "eksik sayfa" kesilmelerinin yoğunlaĢması ve iĢletimi
aksatacak düzeye çıkmasıdır. Sorun, her iĢe ayrılan fiziksel bellek kapasitesinin working
set'i yeterince içermediğinden kaynaklanır.
Bleady Anormalliği
Görüntü bellek düzenlemede sayfalama yönteminin en iyi uygulanması için
içgüdüsel ve sezgisel yöntemlerin kullanımı çoğu kez beklenen sonucu vermez. Örneğin
bir iĢe ayrılan bellek alanı büyüdükçe bu iĢin ürettiği eksik sayfa uyarısını her zaman
azalabileceği ileri sürülebilir. 4 sayfadan oluĢan bir programı ele alalım ve sayfa isteme
sırası,
1-2-3-4-1-2-5-1-2-3-4-5
113
olsun
Bu program FIFO atama yöntemiyle kendisine 4 sayfa ayrıldığında 10
kesilme, 3 sayfa ayrıldığında 3 kesilme üretmektedir.
10.2.2.2. Segmented (Kesimleme) Bellek Yönetimi
Kesimleme, programları mantıksal bütünlük içeren birimlere ayırarak ana
belleğe yükleyen yaklaĢıma verilen addır. Alt yordamlar, yapısal programlama
dillerindeki blok yapıları, iĢlevlerden herbiri mantıksal bir birim olarak
varsayılabilir. Hepsinin ortak özelliği kendi içinde iĢlevsel bir bütün
oluĢturmasıdır (ġekil-55).
0
0
0
0
...
Call [X] <Y >
...
...
C:
...
...
...
60
y:
Segmet B
Call [B] <C >=
100
[A]16
Çalýþma Sahasý
Segmet A
160
ÇalıĢma Sahası
Dizin
Segment MAIN
340
(Program)
Segmet X
Alt Yordam
ġekil-55. Kesimleme Adres Sahası
Þekil:55. Kesilme Adres Sahasý
Ġstem üzerinde sayfalama yönteminde söz konusu ettiğimiz yerel
davranıĢın, mantıksal açıdan bir bütün olan kesimde çok daha yüksek düzeyde
gözlenmesi doğaldır.
Çeviriciler ve derleyiciler kesimleme uygulanan sistemlerde program
içindeki öğelerin adreslerini, kesim numarası ve kesim baĢına göreli konum olarak
çözümlerler. ĠĢletim sayfalama sisteminde olduğu gibi, gerçek adreslerin
hesaplanması için program kesimlerinin bellek içindeki (ana, ikincil bellek)
konumlarını belleyen dinamik adres tablosuna gereksinim vardır. Bu benzerlikten
dolayı kesimleme ve istem üzerine sayfalama yöntemleri sık sık karıĢtırılır. Ġstem
üzerine sayfalamada programların eĢit uzunlukta fiziksel bölümlere, kesimlemede
ise değiĢir uzunlukta mantıksal bölümlere ayrıldığını unutmamak gerekir.
Donanım Desteği
Kesimleme yönteminde adresleme sürecinin göreli kesim tablosundan
baĢlayarak gerçek adresi saptaması ve eriĢtiği kesimin ana bellekte bulunduğunun
sınanması gereklidir. Kesim boyları değiĢir uzunlukta olduğu için eriĢilen öğenin
kesim içinde kaldığının denetlenmesi gereklidir (ġekil-56).
114
ĠĢl.
[MAIN]=0
0
ÝÞLETÝM SÝS.
Sist.
...
Call6 [X] <Y>
...
C=[6]
...
...
160
3460
[X]
Büyüklük EriĢim Statü Adres
Büyüklük Eriþim Statü Adres
0 160 E
E 4000
1
[X]=3
3580
Y:[x]
3800
Y:
[A]
2
0
...
3
120 Y:
...
340
E
E
3460
100
R
E
3800
4
5
360
6
3900
4000
[A]
[MAIN]
60 RW
H
[MAIN]
4160
[A]=5
0
...
100
EriĢim
Eriþim:
E = ĠĢletim
[B]=6
0
...
60
Gerçek Bellek
RE=Ýþletim
= Oku
WR=Oku
= Yaz
W-Yaz
Statü
E=Bellekte
H=Bellekte deðil
C:
Þekil:
56. Kesimleme
Bellek Yönetimi
ġekil-56.
Kesimleme
Bellek
Yönetimi
Program yüklenirken iĢletim sistemi onu segment adı verilen kesimlere
ayırır. ĠĢletim sistemi gerçek belleği en iyi Ģekilde düzenlemek amacıyla
programları kesimlere ayırır. IBM-370 sistemlerinde kesim lokasyon adresi 24 bit
uzunluğunda olup iki bölüme ayrılmıĢtır (ġekil-57).
24 Bit
0
Kesim
Kesim no
Numarasý
8
16
Displacement
31
ġekil-57. Kesim Efektif Adresi
Þekil : 57. Kesim Efektif Adresi
ġekil-57'den anlaĢıldığı gibi 8 bit (28)=256 olduğundan programlar 256
kesime bölünebilir ve her kesim 64K
(65536) geniĢliğinde olabilir.
115
Yazılım Desteği
Adresleme sürecinin iĢlenmesi: EriĢilen adres (A,@)
Kesim Ana
Bellekte mi?
H
Eksik Kesim Uyarısı
E
Göreli konum
(@) : kesim
boyu
>
YanlıĢ Adres Uyarısı
<
ĠĢlem türü :
eriĢim hakkına
uyumu
H
EriĢim Uyarısı
E
ĠĢlem veriyi bozuyorsa durum
göstergesinin günlenmesi
Gerçek Adres
DAT.KONUM+@
Avantajlar
1) Görüntü bellek kavramının getirdiği tüm olanaklar.
2) ĠĢletim sırasında değiĢebilen uzunlukta kesim kullanma olanağının
sağlanması.
116
3) Program ve yordam bağlama (adlandırma=program içi göreli konum)
sürecinin iĢletime kaydırılabilmesi (sadece iĢletime giren kesimler bağlanıyor).
4) Kesimleri paylaĢabilme olanağı (eriĢim hakları tanımlayarak). Örneğin
iki ayrı program COS fonksiyonu kullanıyorsa bu fonksiyonu içeren kesim
bellekte yaratılır ve bu kesim iki program tarafından paylaĢımlı olarak kullanılır.
Dezavantajları
1) Dinamik bellek atama yöntemlerinin tümünde olduğu gibi gerek yazılım
gerekse donanım pahasının artması.
2) Kesimlerin değiĢik boyda olması nedeniyle ana bellek yönetiminin
güçlenmesi.
3) En büyük kesim boyunun ana belleğin fiziksel kapasitesiyle sınırlanması
(sayfalama ile kesimlemenin farkı).
4) Ġstem üzerine sayfalamada olduğu gibi thrashing'i önleyici yaklaĢımların
getirdiği yük.
10.2.2.3. Segmented And Demand-Paged (Kesimleme Ve Ġstenebilir Sayfalı)
Bellek yönetimi
Kesimlemenin sağladığı esneklik ve olanakları koruyarak sakıncalarını bir
ölçüde kaldırmanın bir yolu sayfalama yöntemini kesimler düzeyinde
uygulamaktır.
PaylaĢım, dinamik bağlama,iĢletim aĢamasında boy değiĢtirme gibi
kesimlemenin verdiği olanaklar, herbir kesimin eĢit uzunluktaki fiziksel birimlere
ayrılmasıyla geçerliliklerini korurlar. Ve dolayısıyla ana bellek yönetiminde tüm
bir kesim yerine uzunluğu belli sayfalar kullanılacaktır.
Donanım Desteği
Komutlardaki adresler;
Kesim no + sayfa no + sayfa içi konum
biçimine dönüĢtüğü için her programa bir kesimler tablosu,her kesime de bir sayfa
tablosu gereklidir. (ġekil-58)
117
Kesim Tablosu
L
Sayfa Tablosu
L P
K
P
S
L A
A
L A
A
A
Komut:Kesim , Sayfa , Adres
ġekil-58.
Kesimleme
Ve Ġstenebilir-Sayfalama
Bellek Yönetimi
Þekil: 58. Kesimleme
ve Ýstenebilir-Sayfalama
Bellek yönetimi
118
ĠĢlenen
Ýþlenen
Adresleme Süreci
Kesim no :
K.T. boyu
(L)
Kesim
Sayfa
Tablosu
Sayfa no :
S.T. Boyu
Sayfa Ana
Bellekte
mi?
>
Hata
Ana Bellek DıĢında
Uyarı
>
Hata
E
Uyarı
Avantajları
Yöntem Ģimdiye değin sayılan tüm avantajları içerir.
Dezavantajları
1) Donanımın pahası
2) Yazılım ve tutulacak veri yapılarının karmaĢıklığı.
119
Kesimleme ve istenebilir-sayfalı bellek yönetimi,büyük sistemlerde
baĢarıyla uygulanan ileri düzeyli bir yöntemdir.
10.2.3. Diğer Bellek Yönetim Teknikleri
1) Swapping: Ana bellekteki program kesimlerinin ikincil belleğe
taĢınması. tek ve bitiĢken yeri değiĢir bellek yönetimlerinde tüm bellek için söz
konusu iĢe veya kullanıcıya iliĢkin tüm kesimi çıkarılıyor.
2) Overlay: Bazı kesimlerin ana bellek ile ikincil bellek arasında gidip
gelmesi.
3) Cash Memory: Ana belleğin önüne konmuĢ bellek.
4) Spool: Ġkincil belleklerde giriĢ buffer'larından okuma yapıp yine ikincil
bellek bufferlarında oluĢturması.
120
BÖLÜM 5
CPU YÖNETĠMĠ (PROCESSOR MANAGEMENT)
11.1. Temel Kavramlar
Bir bilgisayar sisteminin performansını arttırmak için mutlaka çoklu
programlama ortamı gerekmektedir. Bu bölümde çoklu programlama ve çok iĢleyicili
sistemlerde kullanılan özel bazı sistemlerden söz edilecektir.
Bir bilgisayar sisteminde çeĢitli paylaĢabilir altyordamların ve kesintiler de dahil
olmak üzere birçok zaman uyumsuz iĢlemlerin kontrolu oldukça karmaĢık sorunlara
neden olmaktadır.
Bu aĢamada bazı temel kavramları anımsamakta yarar vardır.
Process : Kısaca çalıĢmakta olan program olarak tanımlanabilir.
Processor : ÇeĢitli komutları sıradan iĢleme kapasitesi olan donanım birimidir.
Multi-Programming: Ġki yada daha fazla iĢin bir processor tarafından iĢlenmesidir.
Multi-Processing: Ġki yada daha fazla iĢin, bir sistemde bulunan iki yada daha fazla
iĢleyici (processor) tarafından iĢlenmesidir.
Processor yönetimindeki temel sorun, sistemdeki iĢ yükü minimum olacak
Ģekilde processor kullanımını process'ler arasında paylaĢmaktadır. Bir process, sistemde
aĢağıda belirtilen durumlardan birinde bulunabilir;
1) Running : Sistemde bulunan iĢleyici (processor) tarafından komutları iĢlenen
process'dir.
2) Blocked : ÇalıĢmasına devam edilmesi için bir olayın olmasını bekleyen
process'dir.
3) Ready : Beklediği tüm olayları gerçekleĢmiĢ, processor kullanma sırasını
bekleyen process'dir.
Sözü edilen bu üç durum ġekil-59'da gösterilmiĢtir.
Process kesildi
zaman doldu
Running
Bir olayın olması için beklemeye geçme
Process çalışmaya
devam edebilir
Read
y
Blocked
Olması beklenen olay gerçekleşti
ġekil-59. Process'in Durumları
121
Bir process'in Running durumundan Blocked duruma geçmesi için dıĢsal bazı
olayların oluĢması gerekir. (Örneğin g/ç kanalının ve g/ç biriminin hızı, yani
processorun daha hızlı olduğu durumda). Bu gibi olaylar birçok durumda iĢletim
sisteminin kontrolunün dıĢında olur, bu da bir sorun olarak karĢımıza çıkmaktadır.
Processor yönetimi kısaca Ģu Ģekilde özetlenebilir;
a) Her bir process'in izlenmesi,
b) Ready-list'ten çalıĢtırmak için bir process seçilmesi,
c) ÇalıĢmakta olan processleri, çalıĢma zamanını aĢtığı taktirde bırakmak
(burada çalıĢma zamanı, kabul edilen herbir iĢ için ayrılan sabit bir zaman dilimidir),
d) Processler arası iletiĢimi düzenlemek.
Yukarıda sözü edilen iĢlerin hepsini bir iĢletim sisteminde Traffic Controller
adlı yordam yapar. Ancak, iĢlerin çalıĢması için ready-list'den seçen ve Schedular adı
verilen yordamı ayırmakta yarar vardır.
11.2. Schedular
Schedular, processor'ün hangi iĢlere daha fazla hangi iĢlere daha az zaman
ayırması gerektiği konusundaki kararı vermede önemli rol oynar. Schedular'ın
gerçekleĢtirdiği iki olay vardır;
1) Hangi ready process'in çalıĢtıracağının seçilmesi,
2) Time-Slice'ın ayarlanması.
Time-Slice, bir anda çalıĢmakta olan iĢ için ayrılacak olan processor zamanıdır.
Bu zaman aĢıldığı anda bir Timer-Interrupt oluĢur ve process yeniden ready duruma
geçer.
Schedular'ın hangi mantığa göre ready-list'den process'leri seçeceği dikkati çeken
önemli bir noktadır. Schedular, bu seçme iĢini daha önceden herbir iĢ için atanan
öncelik derecelerine göre yapar. Bu öncelik dereceleri ise aĢağıdaki kriterler göz önünde
tutularak verilir;
1)Bought : Daha fazla para veren iĢe daha fazla öncelik verilmesi,
2)Required : Kullanıcılar önem derecelerine göre sınıflandırılırlar,
3)Deserved : Bazı durumlarda ise sistem kendisi bazı process'lere öncelik
derecesi verir. Örneğin kısa iĢlere daha yüksek öncelik derecesi gibi.
Ancak bir sistemde en güzel çözüm dengeli bir öncelik derecesi vermektir.
Örneğin sistemde çok fazla I/O gereksinimi olan (I/O bound) ve çok az I/O gereksinimi
olan (I/O bound) ve çok az I/O gereksinimi olan (CPU bound) iĢler olduğu düĢünülürse,
eğer tüm iĢler hiplerse bu durumda ya I/O kanalları fazla yüklü olacak ve CPU boĢ
kalacak yada tam tersi olacaktır. Dolayısıyla bir sistemde öncelikle (priority) processler
arasında dengeli bir biçimde dağıtılmalıdır. Aynı Ģekilde sistem, kaynaklarını elinde çok
fazla bulundurması gereken processlere de daha fazla yüksek öncelik vermeye çalıĢır.
122
Yukarıda verilen açıklamalara göre (ġekil-59), (ġekil-60)'daki Ģekilde geliĢebilir.
ġekil-60'ta sayfalama bellek yönetimi olan paging, zaman paylaĢımlı bir iĢletim
sistemini göstermektir. Burada bloke olmuĢ processler üç gruba ayrılmaktadır;
1) Terminal I/O için bloke olmuĢ,
2) Disk ya da Tape I/O için bloke olmuĢ,
3) Paging I/O için bloke olmuĢ processler.
DüĢük Öncelikli
Ready (CPU
Bound)
ÇalıĢma zamanı doldu
500 ms çalıĢ
Running
Terminal I/O
Ġhtiyacı
100 ms.
çalıĢ
Disk veya
Teyp I/O
Ġhtiyacı
100 ms.
çalıĢ
Orta Öncelikli
Ready
(I/O Bound)
Disk veya
Teyp I/O için
Bloke Olan
I/O tamamlandı
I/O tamamlandı
Yüksek
Öncelikli Ready
(I/O Bound)
I/O
tamamlandı
Terminal I/O
Ġçin Bloke
Olan
Paging Ġçin
Bloke Olan
ġekil-60. GeliĢtirilmiĢ Scheduling Durumu
123
Bunun yanında Ready-processler de yine üç gruba ayrılmıĢtır;
1) Yüksek öncelikli ready-list'ten process seç,
2) Eğer yoksa daha düĢük öncelikli ready-list'ten process seç,
3) Eğer yoksa en düĢük öncelik dereceli ready-list'tem process seç,
ġekil-60'tan görüldüğü gibi eğer 100 ms herhangi bir I/O gereksinimi olmayan
bir process bulunursa, bu durumda bu geçici olarak CPU bound kabul edilmektedir. I/O
kanallarını daima meĢgul tutmak için I/O bound process daima CPU bound
processlerden daha önce çalıĢılmaktadır. Eğer tüm I/O bound processler bloke olmuĢsa,
bu durumda CPU bound processlere çalıĢma için fırsat verilir ve bu seferde 500 ms'lik
bir çalıĢma zamanı tahsis edilir.
11.3. Traffic Controller
Traffic Controller'unun yaptığı iĢler temel olarak üç grupta toplanabilir;
1) Her bir process ile ilgili durumu takip etmek,
2) Processleri askıya almak yada çalıĢmaya devam etmesini sağlamak,
3) Processler arası iletiĢimi düzenlemek.
Herhangi bir process'in daha sonra iĢine devam etmesini sağlamak için traffic
controller, o iĢin bloke olduğu zamandaki ve processorun durumunu gösteren PSW'ü
saklamıĢ olmalıdır. Traffic Controller dıĢsal olarak (örneğin bir I/O gereksinimi
olduğunda) veya içsel olarak kesintilerle (örneğin I/O bitti kesintisi, zamanlayıcı
kesintisi, page fault kesintisi gibi) çağırabilir. Bir process sistemde o anda mevcut
olmayan yada kullanılmakta olan bir kaynağa gereksinim duyduğunda, Traffic
Controller bu process'i bloke edilmiĢ olan processler kuyruğuna koyar ve ne zaman o
process'in gereksinim duyduğu kaynak sistemde bulunursa o zaman ilgili process'i
ready-list'e alır. Ancak burada Traffic Controller'ın herbir iĢle ilgili durum
değiĢtirmesini çok sıkı bir Ģekilde takip etmesi gerekir, aksi halde sistemde ya bir iĢ
kayıp olur yada büyük karıĢıklık doğar.
Traffic Controller aynı zamanda, eğer sistemde izin verilmiĢse, processlerin
birbirlerine çeĢitli mesajlar göndermelerini ve hatta birbirlerini mesajlar vasıtasıyla
blocked yada ready-list'e kaymalarını kontrol etmelidir. Processlerin bu tür
haberleĢmelerine "Interprocess Communnication" denir.
11.4. Process Senkronizasyonu
Process senkronizasyon sorunu kaynakların paylaĢımına gereksinim
duyulmasından ortaya çıkmıĢtır. Bu paylaĢım koordinasyon ve doğru iĢletim gerektirir.
11.4.1. Race Condition (YarıĢ Durumu)
Ġki processin taranması (scheduling) o kadar önemlidir ki, tarama sırası değiĢtiği
zaman meydana gelen sonuçlar da değiĢir. Bu duruma Race Condition denir (ġekil-61).
124
Bu durum verinin yada kaynakların içsel veya dıĢsal olarak iki yada daha fazla process
tarafından paylaĢılma isteminde oluĢur.
İşletim sistemi
Print İstemi
Process 1
Print İstemi
Yazıcı
Process 2
ġekil-61. Basit Race Condition Durumu
ġekil-61'de iki processin çoklu-programlama ortamında tek bir yazıcıyı
kullandıkları varsayılmıĢtır. Bir process'in iĢi yani o andaki yazacakları bittikten sonra
yazıcıyı ikinci process kullanacaktır. Dolayısıyla sonuçta çıkacak olan output (çıktı) her
iki process'in sonuçlarını karıĢık olarak verecektir. Bu durumu ortadan kaldırmak için
birimi (bu durumda yazıcı) kullanacak olan process'in birimi "Request" etmesi ve
birimle iĢi bitince de "Release" etmesi gerekir. Request ve release iĢlemleri, iĢletim
sisteminin "Traffic Controller" mekanizması tarafından gerçekleĢtirilir. Bu durumda
kullanılmakta olan bir birime gereksinim duyacak olan bir process bloke olacaktır.
Birim onu kullanan process tarafından bırakıldığı zaman bloke edilen process çalıĢmaya
devam edebilir duruma gelecektir. Process'lerin bu Ģekilde birbirleri ile senkron bir
Ģekilde sağlanması tekniğine "Interlocking" veya "Synchronızıng" denir. Burada dikkat
edilmesi gereken önemli bir nokta, gereksinim duyulan birimi kullanmakta olan process
bu birimi release etmezse baĢka bir process tarafından hiç bir zaman kullanılamaz
duruma gelmesidir. IĢletim sistemi tarafından biten bir process'e atanmıĢ tüm birimler o
iĢten release edilerek bu sorun çözümlenir.
11.4.2. Deadly Embrace (Öldürücü KucaklaĢma)
Deadly Embrace, iki process'in birbirlerinden habersiz hiç bir zaman
kullanılmayacak bir birimi ya da kaynağı beklemeleri durumudur. ġekil-62'de gösterilen
iki process'i göz önüne alalım.
125
Supervisor
Ar 1
Process Ar 2
A
Ar 3
Ar 4
Request printer
Request reader
Release printer
Release reader
Br 1
Process
Br 2
B
Br 3
Br 4
Request reader
Request printer
Release printer
Release reader
Printer
Card Reader
ġekil-62. Deadly Embrace Durumu.
ġekil-62'de görüldüğü gibi A ve B process'leri yazıcıyı ve kart okuyucuyu
Release ve Reguest mantığı ile kullanmaktadırlar.Ancak aĢağıdaki durumları göz önüne
aldığımızda Deadly Embrace ile karĢılaĢırız.
1) Ar1, Ar2, Ar3, Ar4, Br1, Br2, Br3, Br4
2) Br1, Br2, Br3, Br4, Ar1, Ar2, Ar3, Ar4
3) Ar1, Ar2, Br1, Ar3, Ar4, Br2, Br3, Br4,
(1) ve (2)'yi göz önüne alalım. Ar1 iĢlediği zaman yazıcı A process'ine verilmiĢ olur.
Eğer A process'i Ar2'yi çalıĢtırırsa (yani okuyucu almak isterse) bloke olur, çünkü
okuyucu o anda B process'i kullanılmaktadır. Aynı Ģekilde B process'i de Br2'yi
çalıĢtırırsa (yani yazıcıyı almak isterse) bloke olur, çünkü o anda yazıcı A process'i
tarafından kullanılmaktadır. Bu durumda "deadly embrace" oluĢtu demektir, çünkü her
iki process de birbirlerini kullanmakta oldukları birimleri bırakması için
beklemektedirler.
11.5. Multiprocessor Sistemler
Bazı sistemlerde, birim zamanda çıkan iĢ miktarının (Throughput) artırılması
için, ek processor kullanılır. Daha önceleri düzenlemiĢ olan çok iĢleyicili sistemlerde bu
ek iĢleyicilerin özel anlamları vardı (I/O kanalları gibi):Çok iĢleyicili sistemlere daha
sonraları büyük hacımlı CPU ve birkaç birim olarak küçük CPU'lar eklenmekteydi. Son
olarak da aynı kapasitede çok CPU bulunan sistemler geliĢtirilmiĢtir. Bu sistemlerin
birbirlerine bağlanması ve o Ģekilde çalıĢması ise son zamanlarda yaygınlaĢan bir
yöntemdir.
ġekil-63'te çoklu programlamanın çok iĢleyicili sistemlerde nasıl kullanıldığı
basit olarak gösterilmiĢtir. Genelde sistemde birden fazla process olduğunu ve her
process'in belli bazı page'lerin gerçek bellekte olduğunu düĢünüyoruz. Bu da sistemde
aktiv durumda bulunan process'lerin sayısının yüksek olmasını sağlamaktadır. Bir
126
iĢleyici çalıĢtırmakta olduğu process'i o process bloke oluncaya kadar yürütür, bloke
olma durumu ortaya çıktığında ise iĢleyici o process'i bırakır ve bir baĢkasına geçer.
Bloke olma durumu bittiği zaman ise yeniden bir iĢleyici o iĢe atanır, ancak atanan bu
iĢleyicinin en son atanmıĢ olan iĢleyici olması gerekmez. Burada dikkat edilecek nokta,
process bloklama tek iĢleyicili sistemlerde olduğu gibi burada da geçerlidir. Bu duruma
bir örnek ġekil-64'te verilmiĢtir.
Supervisor
Processor
No: 1
Process A
Process B
Processor
No: 2
-1. İşleyici Process A
-2. İşleyici Process B
Process C
Process D
Bellek
ġekil-63. Çok iĢleyici Ġle Çoklu Programlama
Supervisor
Process A
Teyp
Gereksinimi
Process B
Process C
Processor
Process D
Teyp
Gereksinimi
ġekil-64. Tek ĠĢleyicili Bloklama
ġekil-64’te A ve D process'leri teyp ünitesi kullanmak istemekteler. Diyelim ki
teyp ünitesini önce Process-A aldıve kullanmaya baĢladı, bu sırada Process-D de teyp
ünitesini kullanmaya kalkarsa bloke olur ve Process-A'nın bu üniteyi bırakmasını bekler.
Burada bloke olan process'in kendisidir, iĢleyici değil.
Genelde çok iĢleyicili sistemlerde çelıĢma, tek iĢleyicili sistemlerde olduğu
gibidir. Ancak burada iĢleyicilerin çalıĢmasını düzenlemek için bazı yöntemler
kullanılmaktadır. Bu yöntemlerden bir tanesi "Software Processor Lockout"dır. Bu
teknik iĢleyiciler arasında veri paylaĢımını sağlamaktadır. Bu teknik ile ilgili, ilk olarak
tek iĢleyicili sistemlerde meydana gelebilecek hataları (ġekil-65), daha sonra iki
127
iĢleyicili sistemlerde meydana gelebilecek olan hataları (ġekil-66) ve son olarak da
çözüm için ne yapılabilir, bunun incelenmesini yapmaya çalıĢacağız (ġekil-67).
Next Serving
17
Work
List
Processor
ġekil-65. Scheduling (Tek Processor)
ġekil-65 tek iĢleyicili sistemleri belirtmekte olup, o anda çalıĢmakta olan process
bittiği zaman;
1) O andaki process'i çalıĢma listesinden bul,
2) Bulunan process'i "Bitti" veya "Ertelendi" Ģeklinde belirle,
3) Bir sonraki çalıĢacak olan iĢin numarasını oku,
4) Okunan numara (burada 17)'lı iĢi çalıĢma listesinden bul,
5) ÇalıĢtırılacak olan process'le ilgili bir not tut,
6) ÇalıĢacak olan process numarasını bir artır.
Sistemlerde çeĢitli tablolar ve listeler tutulmakta olup bu listelerde processlerle
ilgili çeĢitli bilgiler bulunmaktadırlar (job gueuve, task gueve, ready-list, work-list gibi).
Bir process bloke olduğu zaman, onunla ilgili ready-listte bulunan veri bulunur ve
durum kelimesi saklanır. Daha sonra da, bir sonra çalıĢacak olan process saptanır.
Örnekte basit bir dairesel sistem ele alınmaktaydı. Seçilen process'le ilgili çeĢitli
kontroller yapılır ve durum kelimesi tekrardan yüklenir.
Next Serving
17
Processor #1
Work
List
ġekil-66. Scheduling (Çok Processor)
128
Processor #2
ġekil-66'da gösterilen iki iĢleyicili sistemi düĢünelim. Buradaki çalıĢma Ģu
Ģekilde olmaktadır:
1) ĠĢleyici-1 çalıĢma listesindeki process'i bulur,
2) ĠĢleyici-2 çalıĢma listesindeki process'i bulur,
3) ĠĢleyici-1 çalıĢtırdığı process'i iĢaretler,
4) ĠĢleyici-2 çalıĢtırdığı process'i iĢaretler,
5) ĠĢleyici-1 bir sonraki process'i belirler (burada 17),
6) ĠĢleyici-2 bir sonraki process'i belirler (burada 17),
7) ĠĢleyici-1 17. process'i çalıĢma listesinden bulur ve not eder,
8) ĠĢleyici-2 17. process'i çalıĢma listesinden bulur ve not eder,
9) ĠĢleyici-1 bir sonra çalıĢacak olan process no'yu bir artırır (18),
10) ĠĢleyici-1 bir sonra çalıĢacak olan process no'yu bir artırır (19),
Görüldüğü gibi her iki iĢleyici de aynı process'i çalıĢtırmaya baĢladığı zaman, bir
sonraki çalıĢacak olan process'i belirtmek için sayacı bir arttırır ve bu durumda 18.
process atlanmıĢ olur. Bu durumu ortadan kaldırmak için (ġekil-67)'deki mantık
kullanılmaktadır.
Next Serving
17
Process #1
Process #2
Açık
Work
List
Kapalı
ġekil-67 Scheduling (Multiple processors with lockout).
ġekil-67'de görüldüğü gibi bir iĢleyici ötekini beklemek zorunda kalmaktadır.
Bunu da veriye ulaĢmadan önce bir biti kontrol ederek yapar. Eğer bu bit set
edilmemiĢse veri seti kullanılmıyor demektir ve bu durumda iĢleyici veri setini
kullanabilir, kullanmaya baĢladığı zaman ise bu biti set eder, iĢi bittiğinde de tekrar reset
ederek baĢka kullanımlar için açar. Bu durumda olan, yani kullanmakta olan bir veri
setine baĢka bir iĢleyici kullanmak için baktığında, veri seti meĢgul olduğundan geçici
bir süre için bloke olur. Bu duruma "Software Processor Lockout" denir, bu durumda
olan bir iĢleyici hiçbirĢey yapamaz durumda kalır. Bu durumun iki, üç, dört ve sistemde
ne kadar iĢleyici varsa hepsine olması mümkündür.
129
BÖLÜM 6
KULLANICILARIN YÖNETIMI
12.1. GiriĢ
ĠĢletim sistemlerini, bir bilgisayar sisteminin yazılım-donanım geçiĢini sağlayan,
sistem kaynaklarını yöneten, düzenleyen yazılım-donanım kümesi olarak tanımlamıĢtık.
Ekonomik nedenlere dayanan çok kullanıcılı bir ortamda, iĢletim sistemlerinin
çözümlemek zorunda olduğu karmaĢık bir sorun, sistem kaynaklarını kullanıcılar
arasında etkin ve iĢletim amacına uyumlu biçimde bölüĢtürmektir. ĠĢletim sistemleri bu
iĢlevi gerçekleĢtirirken çoğukez birbirleriyle çeliĢen iki tür baĢarım ölçütünü
eniyilemekle yükümlüdür;
1)ĠĢlere iliĢkin baĢarım ölçütleri: ĠĢ yanıt süresi, maliyet, vb.
2)Kaynak kullanımına iliĢkin baĢarım ölçütleri: ĠĢ yanıt süresi, kaynak
kullanım yoğunluğu, kaynak bekleme süreleri.
Sıraladığımız her iki ölçüt kısıtlı bağlamlarda, birbirleriyle doğrudan iliĢkilidir.
Örneğin sistemdeki kaynakların kullanım yoğunluğu arttıkça iĢlere iliĢkin maliyetlerin
düĢeceği açıktır, yada kaynakları iyi dağıtmanın sistemden birim zamanda geçen iĢ
sayısının artması büyük olasılıktır. Ancak bu bağlama herbir iĢ için gözetilen bireysel
yanıt süresini de kattığımızda kaynak kullanımı eniyilenmenin her zaman bir iĢin yanıt
süresini kısaltmayacağı, sistemden birim zamanda geçen iĢ sayısının yine bu süreyi
kısaltma ile iliĢkili olabileceği açıktır.
Sistemde bölüĢülen kaynaklar arasında, yukarıda sıraladığımız oluĢumları
birincil düzeyde etkileyen kaynak, hiç Ģüphesiz AĠB'dir. Sistemde eĢzamanlı çalıĢan
iĢler diğer kaynakları tüketilmek üzere, önce AĠB'ni elde etmek zorundadır. AĠB'nin
yönetimi; görev yönetimi, kısa dönemli planlama (short term scheduling) v.b. adlar
altında; sistemdeki iĢ akıĢının yönetimi ise yaygın olarak iĢ yönetimi (job management),
uzun dönemli planlama (long term scheduling) gibi baĢlıklar altında toplanmaktadır.
Birbirleriyle etkileĢen bu iki yönetim "kullanıcıların yönetimi" adı altında
incelenecektir.
12.2. ĠĢ Yönetimi-Görev Yönetimi ĠliĢkisi
Kullanıcıların yönetimi ġekil-68'de verilen iki aĢamalı bir model üzerinde
açıklanabilir (R.B.Bunt).
130
1
Kullanıcılar
İş
Yönetimi
Görev
Yönetimi
2
Kaynak
Yöneticiler
AİB'leri
Görüntü
Sistemler
Kullanıcı
Yönetimi
n
ġekil-68. Kullanıcıların Yönetime ĠliĢkin Model.
Bu yapıda alt düzeyi, sistemin AĠB'lerini, kurulu görüntü sistemler arasında
bölüĢtüren görev yönetici oluĢturur. Bu kesimin amacı kaynağı en etkin biçimde
değerlendirmektir. Ancak sistemde anahtarlanan tüm görevler bu kesimin denetiminden
geçmeyebilir. Kesilmelerin iĢlenmesinde gördüğümüz gibi, donanım-yazılım geçiĢini
sağlamak üzere donanım çeĢitli görevleri kesin bir sıra düzen içinde iĢletime alır. Bu
nedenle "görev yönetimi" deyimi sistemdeki bu oluĢumu tam olarak
yansıtmamaktadırlar. Ancak donanımca anahtarlanan görevlerin çoğukez kullanıcıya
görünmez nitelikleri ve sistemdeki diğer görevlere oranla daha az zamanla olabilecekleri
gözetilirse yaptığımız genellemenin büyük ölçütte geçerli olduğunu varsayabiliriz.
Üst düzeyi ise "iĢ yönetimi" diye andığımız katman oluĢturur. Kullanıcılar iĢ
denetim dilleri ve sistem yönetim iĢlevleri aracılığıyla gereksedikleri kaynakları,
kullanım biçimlerini iĢletim sistemine tanımlar. Yapılan bu tanımların, gerçekte sistemi
oluĢturan öğeleri tam olarak anlatması gerekmez. ĠĢ yönetiminin iĢlevi herbir
kullanıcının oluĢturduğu, bu "görüntü sistemlerinin" geçerliliğini saptamak, gerçek
sistemin olanaklarıyla gerçekleĢtirilip gerçekleĢtirilemeyeceğini bulmak ve değiĢik
görüntü sistemler arasında uyum sağlamaktır. Bir iĢletim sisteminde paralel olarak
çalıĢabilecek sistem sayısı, sistemin çok iĢ düzeyini belirler.
Görev yöneticisinin AĠB'nin etkin kullanımını gözetmesine karĢılık, iĢ yöneticisi
kullanıcılara sunulan hizmet düzeyini baĢarı ölçütü olarak alır. Örneğin kullanıcıların
yanıt sürelerini azaltmak, bekleme sürelerini sınırlamak gibi. Ġki katmanın değiĢik
ölçütler nedeniyle kimi zaman çeliĢkili eylemlere yönelmeleri olağan ve dengelenmesi
gereken bir sorundur.
131
12.3. ĠĢ Yönetimi-Görev Yönetimi EtkileĢimi
Kurduğumuz model üzerinde iĢ ve görev yönetimlerinin iç içe geçmiĢ birbirini
tümleyen konumlarını gözleyebiliriz. Bu yapı içinde iĢletim aĢamalarını
incelediğimizde, gerçekleĢen adımları aĢağıdaki gibi sıralayabiliriz.
Her kullanıcı sistemle bir iĢ "iĢ sunma" evresiyle iliĢki kurar, iĢletim türüne göre
bu evre kart okuyucu, giriĢ ucu v.b. birimler aracılığıyla gerçekleĢtirilir. Yine iĢletim
türüne bağlı olarak "kaynak bekleme" evresine girer, bu evrede iĢ yönetimi kullanıcının
gereksediği görüntü ortamı gerçekleĢtirmeye çalıĢır (bu evrede beklenilen kaynaklar
arasında AĠB yer almaz). ĠĢ yönetimi kullanıcının belirlediği ortamı sağlayınca iĢ (bir
yada birçok görev biçiminde) "iĢletim evresine geçer, bu evrede beklenilen tek kaynak
AĠB'dir. AĠB'ni de çeĢitli sürelerle kullanan iĢi oluĢturan görevler son aĢamada
"sonuçlanma" evresine girerler. Bu süreçte kullanıcı için sistemde yaratılan ortamda yok
edilir, kullanılan kaynaklar tümüyle sisteme geri verilir. ġekil-69 bu evreleri
göstermektedir.
132
AİB
Kullanım
Evresi
AİB
Bekleme
Evresi
Çalışma
Evresi
Uyarı
Bekleme
Evresi
İşletim
Evresi
Görev Yönetimi
Sonuçlanma
İş yönetimi
Sunuş
Kaynak
Bekleme
Evresi
ġekil-69. Kullanıcıların Yönetimi
12.4. Görev Yönetimi
Görev yönetimi ilgilendiren "çalıĢma evresinde", görevler "AĠB kullanım" ve
"AĠB bekleme" alt evrelerinden birinde bulunurlar. AĠB'ni bekleyen görevlerin bu birim
dıĢında tüm kaynakları sağlanmıĢtır.
Görevler "çalıĢma evresini"ya bir uyarı bekleme (G/Ç sonu, iĢletmen iletiĢimi,
zaman uyumu, v.b.) ya da kaynak yitirdiklerinden terkederler (ġekil-70).
133
Sonuçlama
AİB
Kullanımı
Zaman aşımı
Görev
Yöneticisi
G/Ç, ...
Uyarı
Bekleme
AİB
Bekleme
İşletmen
Kaynak
Yöneticiler
Kaynak
Bekleme
SunuĢ
ġekil-70. Görev Yönetimi
AĠB atama yöntemlerini aĢağıdaki gibi özetleyebiliriz;
1) Öncelik sırasına göre: Toptan iĢ düzeni (iĢ yanıt süreleri).
a) Durgun öncelik
b) Dinamik öncelik
2) Round Robin: EĢ öncelikli görevler (zaman bölüĢümü).
Her görev en çok q zaman birimi süresince AĠB'ni kullanır, bu süre içinde
sonuçlanmaz ya da uyarı bekleme evresine girmez ise kuyruğun sonuna bağlanır.
Sonuçlanma
Kuyruğa
Katılma
q
Uyarı bekleme
Sistemde her görevin iĢletim hızı q/n dir. q büyük tutulduğunda bu yöntem "ilk
gelen önce iĢletilir" gibi uygulanır.
3) Çok düzeyli yönetim: Sıradüzen+zaman bölüĢümü uygulamalarında kullanılır.
134
12.5. ĠĢ Yönetimi
Sisteme sunulan iĢler, iĢletim sisteminin amacına uyumlu bir algoritma ile
iĢletim evresine aktarılırlar. EtkileĢimli bir kullanımda iĢler arasında izlenecek
sıradüzenle, sıradan giriĢli bir sistemde uygulanacak yaklaĢımlarda, büyük farklılıkların
olduğu açıktır. (bkz. Donovan Madnick 216-234).
ĠĢ yönetimini kaynakları kullanıcılar arasında dağıtma açısından incelersek, iki
ana yaklaĢımın varlığını gözleyebiliriz. Ġlk yaklaĢımda iĢ yönetimi, iĢletim evresine
aldığı iĢler için ayrıĢık ortamlar hazırlar, diğer bir deyiĢle paralel çalıĢan ortamlara
atanan kaynaklar AĠB dıĢında çakıĢmaz (ġekil-71).
İş-1
İş-2
.
.
.
İş-n
Kart Okuyucu 1
Satır yazıcı 1
Ana Bellek
Satır yazıcı
2
ġekil-71. AyrıĢık Ortamlar.
Bu yaklaĢımda genellikle izlenen çizgi iĢlerin, çalıĢma ortamlarını, iĢletim
sonuçlanana değin korumalarıdır (IBM DOS;OS/VS).
Bu yaklaĢımın en büyük sakıncası, kaynak kullanım düzeyinin düĢüklüğüdür.
Örneğin bir iĢe atanan kart okuyucu iĢletim süresinin çok az bir kesiminde kullanılmıĢ
olabilir. ĠĢin "beklemede" olduğu sürelerde ana bellek boĢ yere iĢgal edilir. Ayrıca her
iĢe atanacak fiziksel birimlerde sistemin maliyetini önemli ölçüde arttırır. Sistemde
paralel çalıĢacak her iĢin bir kart okuyucu, bir satır yazıcı isteyebileceği düĢünülürse,
belirli kısıtlamalar doğal olarak gçrülür. Durumu iyileĢtirmede yaygın olarak izlenen bir
yolda paylaĢılamayan kaynakları "görüntü kaynak" biçimine sokmaktır. Kaynak atamada
kullanılan ikinci seçenek ise kaynak kullanım düzeyini arttırmayı ve sistem maliyetini
donanım olarak azaltmayı amaçlar. ĠĢ yönetiminin hazırladığı görüntü ortamlar
çakıĢmaya baĢlar (ġekil-72).
135
İş
Görev
Yöneticisi
Yönetimi
..
.
.
Görüntü Sistemler
İşler
ġekil-72. Görüntü Ortamların ÇakıĢması.
ÇakıĢan kesimler paylaĢılan kaynakları göstermektedir. Ana bellek, bir çevre
birimi iĢletim aĢamasında görevlerden sistemce geri alınır. Böylece iĢ için kurulmuĢ
olan görüntü sistemde geçerliliğini yitirir. "iĢ" iĢletim evresinden kaynak beklemeye
geçip, çalıĢma ortamının yeniden kurulmasını bekler. Ya da olanaklı ise her kaynak,
görüntü niteliğine dönüĢtürülüp çoğaltılır.
136
BÖLÜM 7
BĠRLĠKTE ÇALIġAN GÖREVLER
(Concurrent Tasks)
13.1. Process (Süreç) Kavramı
Yürümekte olan program "süreç" olarak tanımlanır. Bir süreç temel olarak üç
durumda bulunabilir; running (yürüme), ready (hazır) ve blocked (tıkalı). AĠB'ni
kullanan bir süreç yürüme, AĠB'ni kullanabilecek bir süreç hazır, g/ç gibi bir iĢlemin
tamamlanmasını bekleyen bir süreç tıkalı durumdadır. Bir AĠB'li bir sistemde hazır
süreçler için hazır süreçler listesi (ready list) ve tıkalı süreçler için tıkalı süreçler
listesi (blocked list) belirlenir. Hazır süreçler listesi öncelik sırasına göre düzenlenir.
Tıkalı süreçler listesinde ise öncelik sırası söz konusu değildir.
ĠĢ verildiğinde hazır listesine ekleme, "sürecin yaratılması" olarak tanımlanır.
Süreç durum geçiĢleri ġekil-73'te gösterilmiĢtir.
Yürüme
ĠĢ Bitimi
Dispatch
g/ç Ġsteği
(tıka)
Zaman
BitiĢi
Hazır
Yokluk
Süreç Yaratılması
g/ç Bitimi
(uyandır)
Tıkalı
ġekil-73 Süreç Durum GeçiĢleri.
ġekil-73'te gösterilen durum geçiĢleri aĢağıdaki gibi açıklanabilir:
1) Hazırdan yürümeye geçiĢ
AĠB'nin boĢ olduğunda hazır listesinin baĢındaki sürece atanması, dispatching
(dağıtım) olarak adlandırılır.
137
dispatch (süreç): hazır ------ >Yürüme
2) Yürüme durumu
Olası geçiĢler,
a) Zaman dilimi bitiĢiyle (timer interrupt) hazır durumuna,
b) GiriĢ / çıkıĢ iĢlemi isteğiyle tıkalı duruma (tıka),
c) ĠĢin bitiĢiyle yokluk durumuna.
3)- Tıkalı durum
GiriĢ / çıkıĢ iĢleminin tamamlanmasıyla hazır durumuna geçiĢ (Uyandır).
Yukarıda sözünü ettiğimiz süreç durum geçiĢleri Ģöyle özetlenebilir;
dispatch (processname):
timerunout (processname):
block (Processname):
Wakeup (processname):
ready running
running ready
running blocked
blocked  ready
Bazı durumlarda sistem fonksiyonlarını çok kısa bir süre için yerine
getiremez.Bu durumda proces suspend (askıya alma) durumuna düĢer, yani çalıĢamaz.
Sorun ortadan kalkınca çalıĢmasına devam eder (resume = yeniden baĢlatmak) (ġekil73).
g/ç BitiĢi
Ready
Blocked
Dispatch
Suspend
Timer
runout
Running
Suspend
Resume
Resume
Suspend
Suspendedblocked
ġekil-73. Suspend - Resume Durumu
138
Sürecin iĢletim sistemindeki gösterimi olan veri yapısına "süreç denetim
kümesi" adı verilir. Bu yapı içinde Ģu bilgiler bulunmaktadır;
. Süreç durumu
. Sürecin kimliği
. Sürecin önceliği
. Sürecin belleğini gösteren konum göstergeleri (pointers)
. Yazaç saklama alanı
Süreçler üzerindeki iĢlemler ise Ģu Ģekilde sıralanabilir;
1) Süreç yaratılması
. Sürecin adlandırılması
. Var olan süreçler listesine eklenmesi
. Önceliğinin saptanması
. SDK'nin yaratılması
. BaĢlangıç kaynaklarının verilmesi
2) Sürecin süreç üretmesi
Anne Baba
Çocuk
1
Çocuk
2
3) Diğer iĢlemler
. Yok etme
. Askıya alma (suspend)
. Askıdan indirme (resume)
. Öncelik değiĢtirme
. Tıkama
. Uyandırma
. Gönderme (dispatch)
13.2. Kesilme ĠĢleme
139
Çocuk
3
Kesilme, iĢleyicinin komut iĢleme sırasını değiĢtiren (eĢzamanlı veya değil) bir
olay olarak tanımlanır. Kesilme olunca denetim iĢletim sistemine verilir, iĢletim sistemi
kesilen sürecin durumunu saklar ve denetim sorumlu kesilme yordamına verilir.
Kesilme çalıĢan bir süreç tarafından baĢlatılabildiği gibi iĢletimde olan süreçle
ilgili veya ilgisiz bir olayla da oluĢabilir.
13.2.1. Kesilme Türleri
IBM iĢleyicilerinde karĢımıza çıkan belli baĢlı kesilme türleri aĢağıda
açıklanmıĢtır.
1) SVC (Supervisor call): Yönetici programa çağrı anlamında olup, kullanıcının
hizmet isteğidir.
2) I/O interrupts (girdi / çıktı kesilmeleri): Girdi / çıktı donanımınca iĢlem
bitimi, yanlıĢ aygıt hazır gibi durumları AĠB'ne duyurmak için üretilir.
3) External interrupts (dıĢ kaynaklı kesilmeler): Zaman diliminin dolması,
klavyede bir tuĢa basılması, çok iĢleyicili bir sistemde baĢka bir iĢleyiciden bir uyarı
gelmesi gibi olaylar.
4) Restart interrupts (Yeniden baĢlatma kesilmeleri): Yeniden baĢlatma
düğmesine basılma gibi.
5) Program check interrupts (Program denetim kesilmeleri): Sıfıra bölme,
ayrıcalıklı komutu yürütmeye çalıĢma, geçersiz iĢlem kodu.
6) Machine check interrupts (makine denetim kesilmeleri): YanlıĢ çalıĢan
donanım.
13.2.2. Context Switching (Bağlam / Kullanım Yeri DeğiĢtirme)
ĠĢletim sistemi her tür kesilmeye yanıt verebilmek için kesilme yöneticileri
(interrupt handlers = IH) denilen yordamlar içerir. Örneğin IBM iĢleyicilerinden altı
kesilme türü olduğundan altı kesilme yöneticisi vardır. (SVC IH, I/O IH, ... gibi). Bir
kesilme oluĢtuğunda iĢletim sistemi kesilen sürecin durumunu korur ve denetimi uygun
kesilme yöneticisine verir. Bu iĢlem "context switching" denilen teknikle
gerçekleĢtirilir.
Program status words (PSW = program durum sözcükleri), süreç durumuna ait
yürütülecek komut adresi, kesilme öncelik denetimi gibi bilgileri içerir. Tek iĢleyicili bir
sistemde bir tane current (Ģimdiki) PSW, altı tane eski PSW (altı tür kesilme için) ve altı
tane de yeni PSW bulunur. Kesilme olduğunda Ģimdiki kesilmenin eski PSW'ne
kesilmenin yeni PSW'ü Ģimdiki PSW'e yüklenir. Kesilme iĢlendikten sonra AĠB ya
kesilen sürece yada hazır olan en öncelikli sürece dağıtılır.
13.3. Kernel (Çekirdek)
Süreçler kesilebilir, kesilmeler küçük bir "çekirdek" tarafından yönetilir.
Çekirdek, iĢletim sistemi iĢlevlerinin sistem süreçleri olarak eĢzamansız yürütülmesini
sağlar. Çekirdek küçük bir monolitik denetleyicidir.
140
Aygıtların çalıĢmalarını aygıt yöneten süreçler denetler. Girdi/çıktıya
gereksinmesi olan kullanıcı, süreç aygıt yöneticisi sürece bir g/ç isteği yollar ve kendini
tıkar. Aygıt hazır olduğunda, aygıt yöneticisi g/ç'ı baĢlatır ve iĢlem bitiĢini beklemek
üzere kendini tıkar. ĠĢlem bitiĢinde donanımdan gelen kesme üzerine çekirdek aygıt
yöneticisini uyandırır. Aygıt yöneticisi de g/ç'ı istemiĢ olan sürece g/ç aygıtının
durumunu bildirir.
Çekirdeğin görevleri Ģunlardır;
1) AĠB'ni çeĢitli süreçler dağıtmak,
2) Kesilmeleri alıp aygıt yöneticisi süreçlere yöneltmek,
3) Kullanıcı süreçlerle aygıt yöneticisi süreçler arasındaki süreçlerarası iletiĢimi
(interprocess communication) sağlamak.
Genellikle çekirdek iĢlevleri mikroprogramlanır.
Yukarıda sözünü ettiğimiz monolitik denetim programının özellikleri Ģunlardır;
1) Kullanıcı süreçleri ve aygıtlar arasındaki iletiĢim kesilemez bir iĢletim sistemi
tarafından sağlanır.
2) Bir aygıt kesilmesi durumunda, denetim programı denetimi alır ve kesilmeyi
iĢler. ĠĢleme sürecince baĢka kesilmeye izin vermez.
3) Küçük sistemler için uygundur.
4) Bütün kesilme yordamları ve tabloları çok bellek gerektirebilir, büyük olabilir
ve tepki yavaĢlar.
14. Birlikte ÇalıĢan Görevler (Concurrent Tasks)
Birlikte çalıĢtırılan görevler, iĢletimleri zaman içinde parelel sürdürülen
görevlerdir. BaĢka bir deyiĢle bir görevin iĢlevi sonuçlanmadan, diğer bir görevin de
çalıĢabilmesidir. Bilgisayar sisteminde birçok AĠB bulunuyorsa, görevler arasında
gerçek bir paralellik, AĠB bir tek yada iĢletim için bekleyen görev sayısı AĠB sayısından
fazla ise AĠB (leri)'nin anahtarlanmasından ötürü görüntü bir paralellik söz konusudur.
14.1. Görevler Arası EtkileĢim
Bir bilgisayar sistemini oluĢturan kesimlerin çoğu kez paralel çalıĢması, iĢletim
sistemlerinin birlikte çalıĢan birçok görevi içermesini zorunlu kılar. Örneğin 9/4
iĢlemleri, gerçek zaman saatinin yönetimi, uygulama programlarıyla paralel yürütülür.
Birlikte çalıĢan görevler, üstlendikleri iĢlevlere bağlı bir sıradüzen içinden iĢletime
alınırlar. Ancak sistemdeki olayların sıralanması buna bağlı olarak, görevler arasındaki
iĢletim sırası ve süreleri önceden kesinlikle kestirilemez. Bunların iĢletim aĢamasında
oluĢturabilecekleri görünümler üzerine, sınırlayıcı önlemler alınmaz ise, varsayımda
bulunmak olanaksızdır.
141
ĠĢletim sistemi içinde, birlikte çalıĢan görevler kaynak bölüĢümün en
zorunlusunun ortak kullanılan veri alanlarında olduğunu söyleyebiliriz. Birçok
bilgisayar sisteminde, iĢletim sistemindeki görevler dıĢında kaynak bölüĢümünün paralel
çalıĢan kullanıcılar arasında da uygulandığını görmüĢtük. Ekonomik nedenlere bağlı
olarak, sistemdeki donanım ve yazılım kaynakları, iĢletim sırasında çeĢitli kullanıcılar
arasında anahtarlanır.
14.2. Görevler Arası Zamanuyumu
Bilgisayar sistemindeki birçok kaynak bölüĢülür olmasına karĢın, bir anda yalnız
bir görevce kullanılabilir. Bu tür tek bir kullanıcıya olanak tanıyan kaynaklara "kritik
kaynak" adı verilir. Birçok görev kritik bir kaynağı bölüĢmek isterse, aralarında yalnız
birinin kaynağı sahiplenmesine yol açacak bir "zaman uyumu" sağlamak zorundadır.
Eğer kritik bir kaynak, bir görevce kullanılıyorsa diğerleri bu kaynağın
kullanımını, kaynak serbest kalana değin ertelemelidirler. Bu nedenle görevler içinde
kritik kaynaklara eriĢim yapan kesimleri "kritik kesimler" olarak adlandırıyoruz. Bir
kaynağa bağlı kritik kesim içinde iĢletim yapan bir görevin, diğerlerinin aynı kritik
kesime gelmesini engellemesi gerekir. Bu olay, "KarĢılıklı DıĢlama (mutual
exclusion)"olarak adlandırılır.
14.3. Birlikte ÇalıĢan Görevlerde Zaman Ġçinde OluĢan Hatalar
Kurduğumuz bir sistemde, biri gerçek zaman saatini yöneten, diğeri de bu saati
aralıklarla bir çevre biriminden görüntüleyen iki görev bulunsun. Zaman saatinin
milisaniyede bir kesilme ürettiğini, görüntülemenin de her saniyede yapıldığını
varsayalım. Her iki görevde de SAYAÇ diye andığımız ortak veri alanını sayıĢım için
bölüĢmektedir. Sistemde yalnızca bir AĠB bulunsun.
Görüntüleme Yardımı
Gerçek Zaman Saati
SAYAÇ DS 0
LH
ALS
STH
.......
1, SAYAÇ
1,1
1, SAYAÇ
Xo
X
LHI
CH
BNE
XHR
STH
1,1000
1,SAYAC
SON
1,1
1,SAYAC
X2
a) SAYAÇ'ın değerinin 1000 olduğu durumlarda görüntüleme yordamı (Xı - X2)
arasında kesilirse, sayıĢımında 1 ms yitirilecektir.
SAYAÇ
1000
1001
0
ĠġLETIM
Görüntüleme yordamı (Xı - X2)
G.Z.S.
Görüntüleme yordamı
142
b) SAYAÇ'ın değerinin 1000 olduğu durumda, görüntüleme yordamı Xo'dan önce
kesilirse, görüntüleme bundan sonra SAYAÇ (mod 1000) olana değin çalıĢmayacaktır.
ĠġLETIM
Görüntüleme yordamı (Xo'dan önce)
G.Z.S.
Görüntüleme yordamı
G.Z.S.
.........
G.Z.S.
G.Z.S.
SAYAÇ
1000
1001
1001
1002
.......
0000
0001
c) Sistemde birden çok AĠB yer aldığında bölüĢüm sorunları daha da karmaĢıklaĢır.
Örnekler izlendiği gibi SAYAÇ kritik bir kaynaktır. Bu kaynağa eriĢen program
kesimleri, kritik kesimlerdir. Kullandığımız örnekte yalnızca görüntüleme yordamının
gerçek zaman saati tarafından kesilebileceğini düĢünmüĢtük. Bu olayın her iki görevin
içinde geçerli olabileceği örnekler de yaygındır. Buna bağlı olarak kritik kesimlerin,
karĢılıklı dıĢlamayı öngören bir yöntemle korunması gerekmektedir.
Verdiğimiz bir örneği aĢağıdaki gibi yeniden düzenlersek;
TIMER
DSH
DC
2
0
LH
ALS
STH
.......
LPSW
1,SAYAÇ
1,1
1,SAYAÇ
TIMER
LHI
LPSW
KAPA DC
CH
BNE
XHR
STH
LPSW
DC
..........
1,1000
KAPA
0,* +2
1,SAYAC
SON
1,SAYAC
1,SAYAC
A
X'7F00' ,* + 2
Yalnız "a" Ģıkkında verdiğimiz hatayı düzeltebiliriz. Diğer hata ise "üretici tüketici" diye adlandırdığımız tüm sorunlarda oluĢur ve görevler arası eĢgüdüm getiren
daha karmaĢık yapılarla çözülür.
14.4. Altdüzeyli Zamanuyumu ĠĢlevler
Kritik kaynakları kullanan program kesimlerinin, iĢletim bütünlüğü açısından
bölünmez olması gerekir. Bir önceki paragrafta bir bütünlüğü sistemi kesilmelere
kapayarak sağlamıĢtık, ancak kullanılan kaynak türlerinin bunlar üzerindeki iĢlemlerin
her zaman kesilmelere kapalı bir iĢletime elvermesi beklenemez. Bu nedenle günümüz
143
bilgisayarlarının çoğunda, görevlerin birbirlerinin iĢletimini karĢılıklı dıĢlayacak
komutlar bulunur. Bu komutların gerçekleĢtirdikleri dıĢlama, yalnızca bir veri eriĢimine
iliĢkin ise bunları "Altdüzeyli Zamanuyumu ĠĢlevleri" diye anıyoruz.
Konuyu incelemek üzere birlikte çalıĢan iki görev düĢünelim, bu görevlerden her
ikisi de kritik bir kesimin iĢletimini içeren bir döngü içinde olsunlar.
Process 1:
do while (true);
begin kritik - kesim end;
diğer komutlar
end;
Process 2:
do while (true);
begin kritik-kesim end;
......
end;
Kritik kesimlerin iĢletimlerinde Ģu iki özelliğin gözetilmesi gerekir;
1) Bir yada çok görev kritik bir kesimin iĢletimini yapmak isterse, en az birinin iĢletimi
gerçekleĢtirmesi gerekir.
2) Kritik kesimde en çok bir görev iĢletim yapabilmelidir.
14.4.1. Ana Bellek EriĢimli Kilitleme
Birden çok AĠB'ni içeren sistemlerde, ana belleğe eriĢim bellek yönetici
donanımın öngördüğü sıradüzen içinde, ardıl biçimde gerçekleĢtirilir. Özellikle ana
belleğe aktarımları içeren iĢlevlerin bölünmez olması ve eriĢilen konumun baĢka bir
süreç tarafından günlenmesi gözetilir. Benzer yaklaĢımı kritik kaynak kullanan yazılım
için de uygulayabiliriz. Her görev kritik bir kesime girmeden önce, baĢka bir görevin de
aynı kaynağa eriĢmediğini sınar. Yada baĢka bir kaynağın aynı kaynağa eriĢmesini
engeller.
Konu baĢında ele aldığımız örneği bu yaklaĢımla inceleyelim. Her görev kendi
kesimini bir mantıksal değiĢken aracılığıyla kilitlesin.
Switch 1 : = false;
Switch 2 : = false;
Process 1 : do while (true);
Kesilmeden do while (switch 2) end;
iĢlenebilmeli switch 1: = true;
kritik kesim
switch 1: = false;
..........
144
end;
Process 2 : do while (true);
Kesilme
do while (switch 1) end;
gelirse?
switch 2: = true;
kritik kesim
switch 2:=false;
..........
end;
Her iki görevin göreli hızları hakkında hiçbir varsayım yapmadığınızda bu
çözüm güvenirliğini yitirmektedir. Örneğin ilk görevin ikincisini kritik kesim iletiĢimini
bitirmesi için döngüde beklediğini düĢünelim. Ġkinci görev, bu kesimden çıkınca "switch
2"değiĢkenini "false" yapacaktır. Bunun üzerine ilk görev, kendi kritik kesimine girmek
üzere do döngüsünü bitirecektir, ancak ikinci görevin 1'den daha hızlı çalıĢıp "switch 1"
true değerine atanmadan iĢletim yaptığını düĢünürsek, her iki görev de paralel olarak
kritik kesimlerinin iĢletimlerini yaapacaklardır.
Bu sorunun ilk doğru çözümü Dekker tarafından verilmiĢtir. Çözümde her iki
görev kritik bölgeye gitmek istediğini mantıksal bir değiĢkeni kullanarak belirtir
(switch 1, switch 2), diğer bir değiĢken (turn) de hangi görevin önce kritik kesime
girmesi gerektiğini göstermektedir.
Bir birinci görev, bir ikinci görev sırayla anahtarlanacaksa bu bir geçerli
çözümdür. Tüm iĢleyicilerdeki ortak değiĢkenler aynı anda günleniyor.
BOOLEAN C1, C2; INTEGER TURN
C1:=C2:=TRUE; TURN:=1
P1:BEGıN A1:C1=FALSE
L1:IF TC2 THEN
BEGIN IF TURN = 1 THEN GO TO L1
C1:=TRUE
B1 : IF TURN = 2 THEN GO B1;
END GO TO A1;
CS1; TURN:=2;
C1:=TRUE; Prog 1;
GO TO A1;
END.
boolean switch 1, switch 2:=false;
ıntegar turn: =1;
Process 1 : begin switch 1 =false;
do while (switch 2=true)
if turn =2
then begin switch 1 = false;
145
do while (turn=2) end
switch1:=true;
end;
end;
kritik kesim
switch 1:= false;
turn:=1;
......
end;
Process 2: begin switch 2:=true;
do while (switch 1 = true);
if turn = 1
then begin switch 2 : = false
do while (turn =1) end switch 2:=true;
end;
end;
kritik kesim
switch 2:= false;
turn:=1
......
end;
14.4.2. Bölünmez komutlar
Ana bellek eriĢimini kilitleyen aktarma komutlarının yanı sıra bu iĢlemi koĢullu
gerçekleĢtirenlerin
kullanılması
kritik
kesimlerin
programlanmasını
daha
kolaylaĢtırmıĢtır. Bunlar arasında IBM 360 sisteminde kullanılan "test and set"
komutunu inceleyelim.
Bu komut biri yerel, diğeri ortak iki parametre kullanır. ĠĢletimde ortak
değiĢkenin içeriği yerel değiĢkene atanır ve ortak değiĢken 1 değerini alır. Bu komutun
iĢletimi bölünemez (ġekil-74).
Yerel
Değişken
Ortak
Değişken
1
ġekil-74. Bölünmez Komut
Otak değiĢken kritik bir kaynağı kullanan görevlerce bölüĢülür, her görevin
kendine özgü birer yerel değiĢkeni vardır. IBM 360'da durum sözcüğündeki koĢul
146
belirteçleri her görev için birer yerel değiĢken niteliğini taĢır. Böylece görevler doğrudan
koĢullu sapma komutlarını kulanabilirler.
Ortak değiĢkenin 1 olması kritik kesimde bir görevin bulunduğunu gösterir.
BaĢlangıçta bu değiĢken 0 değerindedir ve diğer aktarma iĢlemi bölünemez.
integer COMMON;
COMMON :=0
Process 1 : = begin integar LOCAL 1;
do while (true);
LOCAL 1 : = 1;
do while (LOCAL 1 = 1);
T S (LOCAL 1, COMMON); end
kritik kesim
COMMON :=0;
........
end;
end;
Process 2: = begin integer LOCAL 2 ;
do while (true);
LOCAL 2: =1;
do while (LOCAL 2 = 1);
T S (LOCAL 2, COMMON); end
kritik kesim
COMMON :=0;
end;
end;
14.4.3. Semaforlar
Ana bellek eriĢimini kilitleme, "Test
Set" v.b. özel komutların kullanımı,
karĢılıklı dıĢlama sorununu çözmede yeterli yaklaĢımlar olmalarına karĢın, etkinlik
yönünden pahalı çözümlerdir. Kritik bir kesime girmek üzere bekleyen bir görev, bir
döngü içinde diğer bir görevin aynı kaynağa bağlı kritik kesimden çıkmasını bekler.
AĠB zamanını tüketen bu yaklaĢım yerine, kritik bir kesimin giriĢinde tıkanan
görevin "bekler" durumuna geçirilmesi ve AĠB'nin baĢka bir göreve atanması, kritik
147
kesimin iĢletimi bittikten sonra bu görevin tekrar iĢletime baĢlaması daha etkin bir
çözüm olacaktır. Dijkstra tarafından getirilen semafor kavramı, bu yaklaĢımın yalın bir
biçimde gerçekleĢtirilmesini sağlar.
Semaforları yalnız sıfır ve artı değerli tamsayıları içeren değiĢkenler olarak
tanımlıyoruz. Semaforlara öndeğerler atama dıĢında yalnız iki iĢleç uygulanır. Bu
iĢleçler P ve V'dir.
S değiĢkeninin bir semafor olduğunu varsayarsak;
S
baĢlangıç değeri
P (S) if S 0 then S:= S - 1; görevi iĢletime hazır duruma getir
else görevi S'e bağlı kuyrukta beklet.
V (S)
S: = S + 1
if semafora bağlı kuyruk boĢ then
begin S:=S-1;
Kuyruktan bir görevi hazır duruma getir;
end;
Semaforları artı değeri içeren tamsayılar olarak tanımlamamıza karĢın çoğu kez
gerçekleĢtirmede eksi sayılar da kullanıp, bir semafor üzerinde bekleyen görev sayısı da
belirlenir.
P (S)
S : = S - 1;
if S 0 then görev S'ye bağlı kuyruğa konur.
Eğer P iĢleci sonunda bir görev beklemeye girerse bu semafor üzerinde V iĢlemi
yapılana değin kalır.
V (S)
S : = S+1
if S 0 then kuyruktan bir görev hazır duruma getirilir.
V iĢleci sonunda yeni bir görevde hazır duruma gelirse, 0 da iĢletimini paralel
olarak sürdürebilir. Eğer sistemde yalnız bir AĠB varsa, V iĢlecini yapar. Görev ve hazır
duruma getirilen görevden hangisininiĢletileceğine görev yönetici karar verir.
P ve V iĢleçleri bölünmez olduklarından, bir semafor üzerinde iki görev birlikte
P iĢlemini yaparlarsa, bunlardan yalnız biri iĢletimi sürdürür, diğerinin iĢletimi
gecikeceğinden, semaforu "0" olarak bulur ve beklemeye girer.
En çok 1 değerini alan semafora "ikili" semafor (binary semophere) adı verilir.
KarĢılıklı dıĢlama kritik kesimleri P ve V iĢleçleriyle parantez içine alınarak yapılır.
ġimdi önceki yaklaĢımlarda inçelediğimiz kritik kesim sorununu, semaforları
kullanarak çözelim.
integer free;
148
free : = 1;
Process 1 : begin do while (true)
P (free)
kritik kesim
V (free);
.......
end;
Process 2 : begin do while (true);
P (free)
kritik kesim
V (free);
.......
end;
Ġkili semaforlar görevler arası zamanuyumu sağlamada da kullanılabilir.
integer wait;
Wait : = 0;
Process 1 :
begin
......
P (wait)
.......
end;
Process 2 :
begin
.......
V (wait)
.......
end;
Semaforları görevlerin kaynak bölüĢümünde zamanuyumunu sağlamak üzere de
kurabiliriz. Örneğin bir sistemde 4 adet mıknatıslı Ģerit sürücünün bulunduğunu
varsayalım. Mıknatıslı Ģerit sürücüler için 4 öndeğeri atanmıĢ bir semafor kullanırsak
her görev miknatıslı Ģerit sürücüsü gereksediğinde P iĢlemini bitirdiğinde V iĢlecini
kullanarak kaynak bölüĢümü yapar.
MT : = 4;
Görev 1 :
Görev 2 : P (MT)
Miknatıslı
Ģerit sürücü kullanımı.
P (MT)
.....
V (MT)
.....
end
V (MT)
end;
14.4.3.1. Senkronizasyon Semaforları
149
Bu semaforlar ana bellekte 1 birimlik yer iĢgal ederler. Iki alt değiĢkenden
oluĢurlar;
1) Semaforu kullanan iĢ birimlerinin numarası,
2) Sayaç.
Örnek :
WAIT SEM 1
.........
ACT SEM 2
SEM1:
Sayaç
SEM2:
İş birim no
a) WAIT SEM 1 komutu SEM 1 konumundaki semaforu içine iĢ birimi
numarasını yerleĢtirir ve sayacı 1 azaltır. Sayac
0 ise iĢ devam eder, sayac 0 ise iĢ
sistemce bekler duruma sokulur.
b) ACT SEM 2 komutu SEM 2 adresindeki semaforun sayacını 1 arttırır. Sayaç
0 ise iĢ devam eder, sayaç 0 ise SEM 2'deki iĢ birimi nosu ile tanınan iĢ aktif
duruma geçirilir. Ana iĢlem birimi bundan sonra önceliği en fazla olan iĢe atanır.
14.4.3.2. KarĢılıklı DıĢlama Semaforları
Bu semaforlar, bir sayaç ve bekleyen iĢ birimlerini belirleyen bit kuyruğundan
oluĢur.
Sayaç
00100 .....................................
Bekleyen işler kuyruğu
n
Birimdeki bit sayısı
+1
Sistemdeki her iĢ birimi 0 ile n-1 arasındaki tamsayı ile tanımlanması nedeni ile
bekleyen iĢler kuyruğundan her birim bir bit ile gösterilir.
a) ROST SEM3 komutu, SEM3'de baĢlayan semaforun sayacını bir azaltır.
Sayaç 0 ise iĢ devam eder, Sayaç 0 olunca iĢ birimini bekleme kuyruğundaki biti 1'e
dönüĢtürülür ve iĢ bekler duruma konur.
b) RLSE SEM3 komutu, SEM3'deki semaforun sayacını bir artırır, Sayaç 0 ise
iĢ devam eder, sayaç 0 ise bekleyen iĢler kuyruğundaki ilk bit aranıp sıfırlanır ve karĢıt
150
gelen iĢ birimi aktif duruma geçirilir. Bundan sonra ana iĢlem birimi önceliği en fazla
olan iĢe atanır.
.........
ROST SEM 3
.........
ROST SEM 4
.........
RLSE SEM 3
.........
SEM 3
15. Görevler Arası ĠletiĢim
Bir iĢi oluĢturan görevler, iĢlevlerini sürdürebilmek üzere birbirleriyle veri
alıĢveriĢi yapmak zorundadır. KarĢılıklı iletilen veriler her iki görevce bilinen bir
konumda bulunabilir. Örneğin biri dıĢortamdan veri okuyup iĢlem yapan, diğeri de
oluĢturulan sonuçları listeleyen iki görev düĢünelim.
begin array A 0 : N
integer wait
wait : = 0
; B
Process 1 :
begin
do while (true);
read (......:A);
.......
B X :=......A;
.......
V (wait)
end;
Process 2 :
begin
do while (true)
P (wait)
........
write (.....B);
151
0:M
;
end;
end;
Bu örnekte birinci görev daha hızlı çalıĢıp ikinci görev "B" alanını dökmeden bu
alana yeniden taĢıma yaparsa iĢletim bütünlüğü bozulacaktır. B'nin de kritik bir kaynak
olması nedeniyle bu kesimin de semaforlarla korunması gerekir.
begin array A 0 : N , B 0 : M ;
integer wait, free;
wait : = 0; /* görevler arası zamanuyumu sağlayabilmek için* /
free : = 1;
/* kritik kesimi korumak için * /
Process 1 :
begin
do while (true);
read (........A);
.......
P (free);
B X . = .............;
........
V (wait);
end;
Process 2 :
begin
do while (true);
P (wait);
........
write (.....B......);
........
V (free);
end;
Getirdiğimiz bu çözüm görevler arasındaki öncelikler ve okuma / yazma süreleri
ne olursa olsun hatasız çalıĢacaktır. Ancak her iki görevin en etkin biçimde paralel
olarak iĢletilebileceği söylenemez. Her iki görevin davranıĢlarının farklı olabileceğini
düĢünürsek bunları olduğunca zamanuyumsuz kılmanın, etkinliği arttırıcı bir yaklaĢım
olacağı açıktır.
Görevler arasında iletiĢim kurmak üzere bu tampon alanının kullanılması bu
yaklaĢımın sonucudur. Her görev bir diğerinde oluĢan davranıĢlardan etkilenmez.
Tampon bellek kullanırsak yapılan iletiĢimde;
1) Ġletilerin üretilen sırada tüketilmesi (FIFO)
2) Üretimin tampon belleğin sınırlı sığasını aĢmaması,
3) Tüketimin tampon bellekte ileti olduğu sürece yapılması gözetilir.
152
Ġnceleyeceğimiz örnekte iletilerin değiĢmez boyda olduğunu varsayalım.
Tampon bellek "max" ileti olacak sığada olsun. Üretici görev "P" tüketici
"C"dizinleriyle tampon belleği tarasınlar.
Tüketici
Üretici
P
C
Üretim :
b (0) : = S (0)
b (1) := S (1)
----------------b (S-1 mod max) : = S (s)
tüketim :
r (0) : = b (0)
r (1) : = b (1)
---------------r (s) : = b (s-1 mod max)
Ayrıca 0
s-r
max ve 0
s bağıntıları da geçerlidir.
r
Procedura send (Yerel Tampon, Genel Tampon, l, dizin)
begin
P (tampon boĢ)
GT (d)
YT
d d + l (mod max)
V (tampon dolu)
end
Procedure Receive (YT,GT,l;dizin)
begin P (tampon dolu)
YT GT d
d d + l (mod max)
V (tampon boĢ)
end
tampo sığası = max / 2
ĠletiĢim,
153
Send (ileti, tampon)
Receive (ileti, tampon)
yordamlarıyla sağlansın. "Tampon" tampon bellek alanının konumunu
simgelemektedir.
begin
array buffer 0:x ;
integer p,c,full,empty;
p : = c = full : = 0;
empty : = max;
process 1 :
begin array A 0 : N ;
do while (true)
......
ready ( .....A........);
.......
Send (A, buffer);
end;
process 2 :
begin array B 0:N
do while (true)
receive (B, tampon);
.......
Write (......B.....)
end;
procedure
send (m,B);
begin
P (empty);
B (P) :=m;
** N - empty (max - empty)
P:=(P+1) mod max;
V (full);
end;
Procedure
receive (m,B);
begin
P (full);
m :=B(C);
c : =(C+1) mod max;
V (empty);
end;
Ġstediğimiz örnekte parametre aktarımı değer aktarımı ile gerçekleĢtirilmektedir
(by value). Ġletilerin büyük olduğu sistemlerde, tampon bellek alanının sığası ve aktarma
154
iĢlemleri sorun yarattığı için, ileticide de bir tampon alan kullanılır, iletiĢim olayına
yalnız iletim "reference" yerleĢtirilir.
16. Üst Düzeyli Zamanuyum ĠĢlevleri
"Alt düzeyli" olarak sıraladığımız zamanuyum iĢlevleri birlikte çalıĢan
görevlerin yönetimine yeterli gereçleri sağlamalarına karĢın, azımsanmayacak tasarım ve
programlama yükü getirirler. Bunlardan daha karmaĢık ve üst düzeyli iĢlevlerin
gerçekleĢtirilme maliyetinin de yüksek olacağı açıktır. Ancak bir bilgisayar sistemi bu
tür gereçleri içermez, programlama kolaylığı ve güvenirlik açısından benimsenen bir
yoldur.
16.1. Tek Yönlü Posta Kutusu
Posta kutusu deyimi, adını bilinen mektup gönderme sisteminden alır "A" görevi
"B" ile iletiĢim kurmak isterse bir posta kutusunun yaratılmasını sistemden ister.
"Görevler arası iletiĢim" baĢlığı altında incelediğimiz tampon bellek alanı yaklaĢımında
olduğu gibi, atanacak veri alanı görevler arasında iletiĢim sağlayacaktır. Ancak bunun
genel bir mekanizma olması ve iĢletim aĢamasında herhangi bir görevi bu yönde
istemde bulunabilmesi, yaratılan bu veri alanının kendi özelliklerini belirten bir
tanıtıcıyı da içermesini gerektirir (posta kutusunun boyutu, kimin tarafından yaratıldığı,
...).
Bu yaklaĢımla her görev bir diğeriyle bir yönlü iliĢki kurabilir. ĠliĢkinin iki yönlü
olabilmesi için her iki görevinde birer kutu yaratması gerekecektir. Ancak bu çözüm
ileride incelenecek olan kilitlenmelere yol açacaktır.
16.2. Çift Yönlü Posta Kutusu
Ġki görev arasında yaratılan posta kutusunun her iki yönde kullanılması,
zamanuyum ve iletiĢim sorunlarına daha esnek bir çözüm getirecektir. Özellikle soruyanıt türü iĢletimlerde posta kutusu bir yönde soruları, diğer yönde de yanıtları iletmede
kullanılacaktır. Ancak görevlerden birinin diğerini soru yağmuruna tutup, ona yanıt
verecek alan bırakmaması olasıdır. Buna çözüm olarak her soruda bir de yanır verecek
alan öngörülmesi, ya da yanıtın soru için kullanılan alanı da iletilmesi öngörülebilir.
16.3.Çift GiriĢli Posta Kutusu
Birlikte çalıĢan görevler arasında birçok görevin aynı görevle iletiĢim kurmak
istemesi sıkça oluĢan bir durumdur. Örneğin GÇGD, sayıĢımla ilgili görev, v.b. Her
görevin ayrı bir posta kutusu yaratması, bu kutuları tarama iĢlevininde öngörülmesini
gerektirecektir. Tek bir kutunun kullanımı ve buraya gelen iletilerin belirli bir sıradüzen
içinde iĢlenmesi, bu sorunu çözümlemede daha etkin bir yaklaĢım olacaktır.
16.4. Kapılar
155
Posta kutusu yönteminde, iletiĢim kuran her iki görevinde kullanacakları
kutunun adı üzerinde uzlaĢma sağlamaları gereklidir. Ancak kimi durumda görevlerden
birinin iletilerin kime gidip, kimden geldiğini bilmesi anlamsızdır. Özellikle kullanıcı
görevleri ve sistem görevleri arasında gerçekleĢtirilen iletiĢimde, sistem görevleri
hizmet isteyen görevin kimliği ne olursa olsun iĢlevini benzer biçimde sürdürecektir. bu
nedenle posta kutusu sistemine dolaylı bir adresleme türü katılarak, görevlerden
kimilerinin iletiĢimlerini doğrudan posta kutusu aracılığı ile değil, bir kapıya bağlı posta
kutusu aracılığı ile yapmaları sağlanır. Bu yaklaĢıma bir mektup dağıtım sisteminde,
kullanıcının adresine yollanan mektuplar yerine, postanede ayrılan posta kutularının
kullanımına benzetebiliriz. Postacı mektubu kutuyu kimin kullandığını bilmeden her
zaman aynı yere atacaktır. BaĢka bir benzetme olarak birçok FORTRAN derleyicisinin
giriĢ çıkıĢlar için yaptığı varsayımları gösterebiliriz. Örneğin Burroughs 6800 MCP
FORTRAN derleyicisi, uygulama programlarının 5 nolu kapıyı giriĢte, 6 nolu kapıyı
kullandığını varsayarak gereken amaç programı üretir. Ancak uygulayıcı bu kapıya
istediği posta kutusunu bağlayarak her iĢletimde ayrı bir birimle iletiĢim kurar.
? FILE 5 (KIND=TAPE, ...)
P.K.
? FILE 5 (KIND=DISK, ...)
P.K.
READ (5, 100)
16.5. Hoare Monitor' u
Monitor bir sistemde bir çok görevin ardıl olarak bölüĢtüğü yordam kümesine
verilen addır. ĠĢletimim herhangi bir aĢamasında bir monitoru kullanmak isteyen bir çok
görevden yalnız biri bu kesim içinde bulunur. Bu yapıda, görevler arasındaki zaman
uyum ve karĢılıklı dıĢlama sorunları çözmede yeterli ve esnek bir yaklaĢımdır. ĠĢletim
sisteminde kaynak atama yapan yordam kümeleri birer monitor'dur. Örneğin, ana bellek
atamada böyle bir yordam istemleri teker ve kesin bir sıradüzen içinde yanıtlar.
Görevler arası iletiĢimi sağlamak üzere monitor kavramının kullanımı,
görevlerin ortak veri alanı tutma zorunluluğunu kaldırır. Böylece yazılım içindeki kritik
kesimler büyük çoğunlukla elenir. BaĢka bir deyiĢle yalnız semaforları kullanarak
yapılan programlamada, kritik kesimler bir çok program içine dağılmıĢtır. Monitor
bunların tek bir yönde ortak biçimde kullanılmasını sağlar (ġekil-75).
156
Monitor:
Kritik
Kesimler
CALL
CALL
CALL
(a)
(b)
ġekil-75. a)Monitorsuz Çözüm
b)Monitor Kullanımı
16.6. Monitor Görevler
Bu yaklaĢımda her ayrı kritik kesimi içeren yordam, ayrı bir görev aracılığı ile
iĢlenir. Bir zamanuyumu, bir iletiĢim yapmak isteyen görev, iliĢkin özel görevin
anahtarlanmasını ister. Bu yönde birçok görevden gelen istemler görev yönetici
tarafından sıraya konacağından, karĢılıklı dıĢlama sorunu sistemde var olan bir
mekanizma tarafından doğal olarak çözülür.
Monitör görevi istemleri ardarda karĢılayarak, kritik bir kesimin yalnız bir görev
için iĢletilmesini sağlar. Görevler arası iletiĢimde yapılan istemler hakkında yeterli
bilgileri iletmede doğal bir altyapı oluĢturur. (ġekil-76).
Görev
A
Görev
B
Görev
X
Monitör
Görev
ġekil-76. OluĢan Altyapı.
157
Bu yaklaĢım tüm esnekliğine karĢın gerektirdiği ek veri yapıları ve anahtarlama
iĢlemlerinde yitirilen süreler açısından pahalı bir çözümdür.
17. Örnekler
17.1. Okuyucu Ve Yazıcılar
Birlikte çalıĢan görevler arasında aynı kaynağı bölüĢen iki tür görevin
bulunduğunu varsayalım. "Okuyucular" olarak adlandırdıklarımız, kaynağa paralel
olarak eriĢip iĢletimlerini birlikte sürdürebilirler. "Yazıcılar" ise kaynakta yapacakları
iĢlem nedeniyle (örneğin günleme) kaynağa tek baĢlarına eriĢmesi gerekenlerdir. Bu tür
görevlerin iĢletim tutarlığını bozmadan birlikte çalıĢmalarını sağlayacak zamanuyum
mekanizmasını kullanarak çözüm sürecini yalınlaĢtırmak üzere yalnız yazıcı ve
okuyucuların birbirlerini dıĢladıklarını düĢünelim.
18. Kilitlenme (Deadlock)
Kilitlenme iki yada daha çok görevin karĢılıklı olarak hiç bir zaman
gerçekleĢmeyecek koĢulları beklemeleriyle oluĢan bir durumdur. Her görev yalnız bir
baĢka görevin sağlayacağı bir koĢulu beklerse ve bu görevler de kapalı bir zincir
oluĢturursa, kilitlenme kaçınılmazdır. Her görev çalıĢabilmek için, bir diğerinin
izletilerek gereksediği koĢulun sağlanmasını beklediğinden hiçbiri çalıĢmaz. Örnek
olarak sistemde sistemde ikili semaforlarla korunan bir kart okuyucu ve bir satır yazıcı
bulunduğunu düĢünelim. Paralel çalıĢan iki görev de bu kaynaklar için çapraz istemlerde
bulunurlarsa kilitlenme oluĢacaktır.
Görev A
Görev B
P (Kart okuyucu)
P (Satır Yazıcı)
P (Satır Yazıcı)
P (Kart Okuyucu)
Kilitlenme olayını sürekli ve geçici diye sınıflayamayacağımız iki tür kaynak
üzerinde inceleyelim. Sürekli kaynakları kart okuyucu, satır yazıcı gibi paralel görevler
arasında ardıl olarak bölüĢülenler olarak, geçici kaynakları tampon bellek alanları,
iletiler gibi bir görevce üretilip diğerlerince tüketilenler olarak tanımlıyoruz.
18.1. Sürekli kaynaklarda Kilitlenme
Sürekli kaynakların kullanımında kilitlenmelerin oluĢması için aĢağıda sıralanan
koĢulların gerçekleĢmesi gerekir.
1) KarĢılıklı dıĢlama : Bir kaynağın aynı anda yalnız bir görev tarafından
kullanılabilmesi (aynı anda bölüĢülememesi).
2) Non-preemtive Scheduling : Bir göreve atanan kaynakların yalnız bu görev
tarafından özgür bırakılması, iĢletim sisteminin bu kaynaklara kullanımda iken el
koyamaması.
158
fiziksel olarak olanaksız
maliyet açısından zor
3) Ġstem üzerine kaynak atama : Görevin gereksediği kaynakları teker teker iĢletim
aĢamasında elde etmesi (atıl sığa yaratmakta).
4) KarĢılıklı Beklenti : Yukarıdaki koĢulların bulunduğu bir ortamda,birlikte çalıĢan
görevlerin kaynaklarının kesiĢmesi. Kilitlenmeleri önlemek üzere birinin yada
birçoğunun oluĢmasını engellemek yeterlidir. Ancak sıraladığımız bu koĢullar çoğu
kez sistemde fiziksel ve ekonomik nedenlerden kaynaklanmakta ve sistemin genel
baĢarım değerlendirmesindeki ölçütler nedeniyle kaçınılmaz olarak oluĢmaktadır.
1) KarĢılıklı dıĢlamayı kaldırmak çoğu fiziksel birim için olanaksızdır, bu sorun yalnız
sistemde yeterince birim bulundurmakla çözülebilir.
2) IĢletim aĢamasında kullanılan kaynakları gerektiğinde geri alan bir atama yönetimi
uygulamak çoğu fiziksel kaynak için olanaksızdır. Ancak AĠB ve ana bellek gibi
yeniden kullanılan birimler gereken yatırımla iĢletim aĢamasında geri alınıp baĢka
bir görevin kullanımına verilebilir.
3) Kaynakları iĢletimin baĢında tümüyle atayıp, görüntü ortamını yaratamadığımız
görevleri de beklemeye almak, sistemde atıl kapasite yaratan verimsiz bir
yaklaĢımdır.
4) KarĢılıklı beklemeyi önlemek üzere, kaynak istemlerini geliĢ sırasına göre rasgele
değil, sistemin karĢılayabileceği bir yöntemle yanıtlamak (görüntü ortamları kesiĢen
görevleri birlikte iĢletime almamalı ).
18.2. ĠĢletim Sistemlerinde Kilitlenmelerin Çözümlenmesi
ĠĢletim sisteminin niteliği ne olursa olsun , her sistemde kilitlenme olayı
karĢısında açık yada kapalı biçimde benimsenen bir yaklaĢım bulunur. Bunlar;
1) Kilitlenmeyi engelleme ,
2) Kilitlenmeyi otomatik olarak farketme ,
3) Sistem iĢletmeninin kilitlenmeyi yakalaması ,
diye üç ana grupta toplayabiliriz.
Kilitlenmenin önlenmesi; kaynakların görevler atanması aĢamasında
uygulanan,
ilerde
oluĢabilecek
kilitlenmeleri
yakalayacak
algoritmalarla
gerçekleĢtirilir.Yeni görevin gerekseyeceği kaynaklar kilitlenme oluĢturabilecekse, bu
görev iĢletime alınmaz.
Kilitlenmenin otomatik olarak farkedilmesi; iĢletim sisteminin birlikte çalıĢan
görev kümesinin tüketmekte olduğu kaynaklar üzerinde yaptığı sayıĢımlar ortaya çıkar.
Ancak bu aĢamada sorunun kolay bir çözümü yoktur. ĠĢletim sistemi yada sistem
iĢletmeni, birlikte kilitlenme olmadan tutarlı biçimde çalıĢabilecek görev kümesini
saptar, bunların dıĢında kalanlar sonuçlandırılır. Bu çözümün çoğu kez birbirine bağlı
görevler nedeniyle, tüm görevlerin durdurulmasına yol açabileceği gözden
kaçmamalıdır.
159
Üçüncü yaklaĢım kilitlenmelerin az raslanan bir durum olduğu varsayımına
dayanmaktadır. Sistemde kilitlenmeleri önleyecek hiç bir önlem alınmadığı gibi
kilitlenme oluĢtuğunda bunu çözmek üzere ek bir önlem öngörülmemiĢtir. Sistem
iĢletmeni bu durumda yanlızca sistemi kapatıp iĢletimi yeniden baĢtan alır, arada
yitirilen iĢler kayıp sayılır.
18.3.Kilitlenmeleri Engelleme
Bir önceki kısımda önerilen yaklaĢımlar sırasında en sağlıklısı hiç kuĢkusuz
kilitlenmeleri oluĢmadan önlemektir. Dinamik kaynak atama ise bölüĢümün uygulandığı
sistemlerde gerek sürekli gerekse geçiçi kaynakları atarken izlenecek kıstaslar vardır.
Bunlardan temel saydıklarımıza değinecegiz.
18.3.1.Banker Algoritması
EĢdegerli kaynaklar üzerinde birlikte çalıĢan görevlarin kilitlenme
oluĢturmaması için, eldeki kaynaklara göre atama yapan bir algoritma Dijkstra
tarafından 1965'de tanımlanıp çözülmüĢtür. Sorunu, değiĢmez bir kapitali olup, bunu
müĢterileri arasında bölüĢtüren bir bankerin açık vermeden herkese para sağlaması
olarak tanımlayalım .Her müĢteri ödünç para almadan önce gereksediği toplamı
belirtmekte ve bankerde bu istemi toplam kapitalini aĢmadığı sürece karĢılamalıdır.
Bu ticari iliĢki sırasında müĢteri ödünç alma ve geri verme iĢlerini her seferinde
bir birim olarak sürdürmekle yükümlüdür. Banker müĢteriye en çok sınırlı bir süre
bekleyeceğini garanti etmekte, buna karĢılık müĢteri de tüm gereksinimi karĢılandığında
parayı sınırlı bir sürede kabul etmektedir.
Banker her ödünç para
isteminde aĢağıdaki algoritmayı uygulayarak,
batmayacağını önceden hesaplamakta ve istemi kendisi için tehlike olmadığı sürece
karĢılamaktadır.
Kapitali 10 lira olan ve 3 müĢteri ile iĢ yapan bir bankerin aĢağıdaki durumda
bulunduğunu varsayalım.
MüĢteri
--------------1
2
3
En fazla gereksinimi
------------------------4
6
8
Ödünç aldığı
--------------2
3
2
Toplam ödünç = 18 Lira
Kasa = 3 Lira
160
Geriye kalan
---------------2
3
6
Üçüncü müĢteri bu durumda iki lira daha ödünç almaya çalıĢırsa, banker açık
verecektir. Çünkü birinci müĢterinin istemini karĢılaması için elinde yeterli para
kalmayacaktır. Bu nedenle ödünç verme algoritmasının kasada her zaman en az bir
müĢterinin geri kalan gereksinimini karĢılayacak biçimde düzenlenmesi gereklidir.
kasa :=kapitai;
for i:= Step 1 Until N do
begin kasa :=kasa - ödünç (i);
gk(i) := efg(i) - ödünç(i);
karĢılanamaz(i):=true;
end;
Algoritmanın baĢlangıcında, tüm iĢlemlerin karĢılanıp karĢılanmayacagı
bilinmediğinden, her müĢteri için "karĢılanamaz" diye bir mantıksal değiĢken
kullanılmaktadır.
flag :=true;
do while (flag);
flag:=false;
for i:=1 Step 1 Until N do
begin if karĢılanamaz(i) and gk(i) kasa
then begin karĢılanamaz(i):=false;
kasa:= kasa + ödünç(i);
flag:=true;
end;
end;
end;
if kasa= kapital
then banker ödünç verebilir
else
" açık
"
Örnek uygulama 1:
Örnek uygulama 2:
3 kullanıcı 2 birim istedi
kasa:=1 kasa < kapital
1 kullanıcı 2 birim istedi
kasa:=0 kasa = kapital
18.3.2. Sıradüzensel Kaynak Atama
Birlikte çalıĢan görevlerin kilitlenme oluĢturmasını önlemede uygulanan bir
yöntem de, sistem kaynaklarını dondurulmuĢ bir sıra düzen içinde atamak/özgür
bırakmaktır. Bir sistemdeki aynı tür kaynakların kümeler dizini ve bunlar arasında bir
sıralama yapıldığını düĢünelim. Eğer;
1)Görevler gereksedikleri kaynaklar arasında, aynı kümede bulunanlar için tek bir atama
isteminde bulunurlarsa,
2)i düzeyinde bir kümeden kaynak sağlamıĢ bir görev yalnız i+1, ..., i+n gibi daha üst
düzeylerden kaynak sağlayabiliyorsa,
161
3)Bir görevce tüketilen i düzeyindeki kaynaklar (i-1) düzeyinden önce özgür
bırakılıyorsa,
bu sistemde kilitlenme oluĢmaz.
1
2
CR (3 tane)
LP (4 tane)
Kaynak Atama
Özgür Bırakma
MT (4 tane)
i
Çok önemli kritik kaynağın (az kullandığımız) düzeyini düĢük tutmak gerekir.
Görev 1
Görev 2
P(CR)
P(LP)
P(CR)
P(LP)
V(LP)
V(CR)
V(LP)
V(CR)
18.3.3.Görevlerde Sıradüzensel ĠletiĢim
Ġki görev arasında tampon bellek kullanarak yapılan tek yönlü iletiĢim hiç bir
zaman kilitlenmeye yol açmaz. Ancak çoğu uygulamada iletiĢimin iki yönlü kurulması
gerekmektedir. Bu durumda her iki görevin ileti beklemesi yada ileti gönderecek tampon
belleği doldurması kilitlenmelere yol açar. Görev sayısı birden çok olduğu durumda,
karĢılıklı beklemelerin oluĢması daha büyük olasılıktır.
162
A
B
C
Görevlerden her biri diğerinin iletisini beklemektedir.
Örnekte de izlendiği gibi görevlerin davranıĢlarının birbirinden bağımsız olması,
her koĢulda bir bekleme zinciri oluĢturmaktadır. Bu bekleme zincirini kurmak üzere
görevler arasında bir sıradüzen kurup iletiĢimin üst düzeyli görevlerce yinetilmesini
görelim. Buna göre üst düzeydeki görevler daha alt düzeydekilere iletiler göndersin, alt
düzeydekiler de yalnız bu iletileri yanıtlasınlar. Böylece sorular bir yönde, yanıtlar da
diğer yönde iletilir.
Ancak bu yaklaĢımda da kilitlemeyi oluĢturacak görünümler tümüyle ortadan
kalkmaz. A, B, C, D diye andığımız dört görevin ġekil-77' de belirtilen sıra düzen içinde
iletiĢim kurduklarını düĢünelim. Çizimdeki her bir ok, bir tampon alanı göstermektedir.
Boş
A
Dolu
D
B
Dolu
Boş
C
ġekil-77. Dört Görevin Ġletimi
En alt düzeyli D görevinin B 'den bir soru beklemekte olduğunu varsayalım, bu
arada C, D 'ye bir soru sorup yanıtını beklerse ve A görevi de C için aynı iĢlemi yaparsa,
B görevinin A 'dan ileti beklemesi durumunda kilitlenme sıradüzensel yaklaĢıma karĢın
oluĢur.
Kilitlenme sıradüzensel iletiĢimde iki görev arasında da oluĢabilir. Örneğin A
görevi B'ye bir dizi soru yönelttikten sonra B'yi beklemeye baĢlasın. Eğer her iki
yandaki iletiĢimden de bir tampon alan bu arada dolarsa kilitlenme oluĢur (ġekil-78).
163
Soru
Yanıtlar
ġekil-78. Iki Görevin IletiĢimi
Her iki örnekten kilitlenme üzerine Ģu sonuçları çıkarabiliriz;
1) Bir görev ağında iki görev arasında birden fazla iletiĢim yolu bulunuyorsa
kilitlenme oluĢabilir.
2) Bir ileti alınmadan ikinci birim yollarda kilitlenmeye yol açabilir.
Görevler arası iletiĢimde kilitlenmeyi önlemek üzere aĢağıdaki koĢulların
gözetilmesi yeterlidir;
1)Üreticiler ve tüketiciler arasında bir sonraki iletimin kime gönderileceği konusunda
sürekli bir anlaĢma sağlanmalıdır,
2) Üretici ya da tüketici bir görev içinde, iletileri iĢleyen kesimler sınırlı bir sürede
sonuçlanmalıdır,
3) Görevler arası iletiler kendi baĢlarına bir bütün oluĢturmalıdırlar, baĢka bir değiĢle bir
görev bir ileti aldığında onu yanıtlamak üzere, üreticiden baĢka bir beklentisi
olmamalıdır,
4)Yanıtı beklenen bir ileti, yalnız yanıtın gönderebileceği bir tampon alanın bulunması
durumunda yollanmalıdır.
164
BÖLÜM 8
VM ĠġLETĠM SĠSTEMĠ
19. GiriĢ
Bir görüntü makinası gerçek bir makinanın yanıltıcı bir görüntüsüdür. Tek bir
gerçek makinayı birden fazla gerçek makinaymıĢ gibi gösteren bir görüntü makinası
isletim sistemi tarafından oluĢturulur (ġekil-79). Kullanıcı açısından bakıldığında,
görüntü makinaları gerçek makinalara çok benzer Ģekilde yada tamamen farklı
olabilirler. Pek çok görüntü makinası iĢletim sistemi geliĢtirilmiĢtir. Bunların en çok
kullanılanı VM/370 dir.Bu sistem IBM/370 den sonraki pek çok sistemde de
kullanıldığı için sadece VM olarak adlandırılır.
VM, bir IBM sistem 370 bilgisayarını (yada benzer bir donanımı) yönetir, ve
terminallerdeki kullanıcıların her birine pek çok giriĢ/çıkıĢ aygıtları ile beraber tam
bir sistem 370 görüntüsünü verir. Her kullanıcı farklı bir iĢletim sistemi seçebilir. VM,
Her biri kendi görüntü makinasında olmak üzere bir kaç farklı iĢletim sistemini
aynı anda çalıĢtırabilir. VM kullanıcısı IBM'ın bir kaç farklı iĢletim sisteminden
herhangi birini yada evde geliĢtirilmĢ bir sistemi çalıĢtırabilirler. VM kullanıcıları
ġekil-80' deki IBM iĢletim sistemlerinin versiyonlarını kullanırlar.
165
Operator
Konsolu
Okuyucu
Punch
Yazýcý
370/168
görüntü makina
iþletim sistemi
görüntü
konsolu
görüntü
konsolu
DOS
CMS
768 K
görüntü
deposu
CMS
320 K
görüntü
deposu
görüntü
okuyucu
görüntü
okuyucu
görüntü
punch
görüntü
punch
görüntü
yazıcı
görüntü
konsolu
512 K
görüntü
deposu
görüntü
okuyucu
görüntü
punch
görüntü
yazıcı
görüntü
yazıcı
ġekil-79. Tek Gerçek Makinasıyla YaratılmıĢ Birçok Görüntü Makinası
166
Batch yada tek kullanıcılı etkileĢimli sistemler
DOS
DOS/VS (ve DOS/VSE)
OS/PCP
OS/MFT
OS/MVT
OS/VS1
OS/VS2 (MVS)
OS-ASP
PS 44
RSCS
Çoklu EriĢim Sistemleri
WM/370
OS'un Timesharing Seçeneği
Conversational Sistem
CMS
ġekil-80. Görüntü makinası iĢletim sistemleri
Multiprogramming sistemleri (ġekil-81) tek bir makinanın kaynaklarını farklı
iĢlemler için paylaĢırlar. Her iĢleme gerçek makinanın kaynaklarının bir bölümü atanır.
Bunlar, boyut ve olanak olarak kulandıkları gerçek makinadan daha küçük bir görürler.
Görüntü makinası multiprogramming
sistemleri
(ġekil-82) gerçek bir
makinanın kaynaklarını farklı bir Ģekilde paylaĢırlar. Bu sistemler bir tane gerçek
makinayı birden fazlaymıĢ gibi gösterirler. Gerçek makinanınkilerden daha fazla
olanaklarla görüntü iĢlemci, bellek ve g/ç aygıtları meydana getirirler.
167
Geleneksel
multiprogramming
işletim sistemi
işlem
n
işlem
1
işlem
1
işlem
1
......
Şekil-81. Geleneksel Multiprogramming
Görüntü makine
multiprogramming
işletim sistemi
görüntü
makina
n
görüntü
makina
1
görüntü
makina
2
görüntü
makina
3
........
Şekil-82. Görüntü Makina Multiprogramming
VM'in ana bölümleri Ģunlardır:
Control Program (CP)
Conversational Monitör System (CMS)
Remote Spooling Communications Subsystem (RSCS)
Interactive Problem Control System (IPCS)
CMS Batch Facility
CP, görüntü makinalarının çalıĢabileceği ortamı yaratır (ġekil-83). CP, görüntü
makinası ortamının altında yatan gerçek makinayı yönetir. Her kullanıcıya, gerçek
makinanın iĢlemci, bellek ve g/ç aygıtları gibi imkanlarına eriĢim olanağı verir.
Sistem/360, sistem/370 ve diğer uyumlu bilgisayar sistemlerini kontrol eden çeĢitli
iĢletim sistemlerini destekler.
168
CMS, programları etkileĢimli olarak geliĢtirmek için güçlü imkanlar sunan bir
uygulama sistemidir. Editörler, dil çeviricileri, çeĢitli uygulama paketleri ve debug
imkanlarını içerir.
RSCS, VM'e bir teleiĢlem ağı üzerinden kütük gönderme ve alma imkanı verir.
IPCS, on-line analizler ve VM' in yazılım problemleri ile baĢa çıkmak için kullanılır.
IPCS problemleri tespit edilmesini sağlar ve farklı tiplerdeki hataların frekanslarını
rapor etmek için çeĢitli istatistiksel olanakları vardır.
Çok yönlü
batch
bölümleri
Çok yönlü
batch
bölümleri
Çok yönlü
batch
bölümleri
DOS/VS
DOS/VS
batch'in bir OS/MVT
Batch İşletimiönceki işletimi
Görüntü
370
Görüntü
370
Görüntü
370
Bir
kullanıcı
Bir
kullanıcı
CMS
CMS
Görüntü
370
Görüntü
370
CMS
Görüntü
370
Görüntü
Donanımı
CP
Gerçek
DONANIM
Sistem / 370
ġekil-83. CP Çok Yönlü Görüntü Makine Çevre Birimleri Yaratma
CMS Batch Facility, kullanıcıya bir CMS görüntü makinasıyla etkileĢimli
iĢ yaparken aynı anda batch processing için sisteme daha büyük iĢler verme imkanı
sağlar CMS Batch, sistem operatörünce kontrol edilen kendi görüntü makinasında
çalıĢır. ĠĢ kontrol deyimleri yapılacak iĢlemi tanımlar. ĠĢler bir kart Ģeklinde girilir;
gerçekten kartlara delinebilirler yada bir CMS kutsundaki kart görünümlü kayıtlar
olarak da verilebilirler. ĠĢ çıktıları, sistemin gerçek çıkıĢ aygıtlarına ya da iĢi veren
kullanıcının kendi görüntü makinasının çıkıĢ aygıtlarına gönderilebilir. CMS Batch
Facility, iĢi veren kiĢiyi iĢ baĢlarken ve biterken uyarır.
CP altında çalıĢan görüntü makinaları, VM pek çok makinayı aynı anda
çalıĢtırdığı için daha yavaĢ çalıĢmaları haricinde gerçek bir makinaymıĢ gibi
çalıĢırlar.
Görüntü makinası kavramının bir kullanımıda ürünü çalıĢtırmak için
install etme çalıĢması devam edereken yeni iĢletim sistemlerni yada yeni geliĢmelere
hatadan arındırır. CP' nin sistem programcısına bir görüntü makinası üzerinde kontrol
imkanları veren pek çok fonksiyonu vardır.Bu kontrol, programcının gerçek bir
makinanın konsolunda otururken sahip olduğu kontrole benzerdir. Örneğin, CP
komutları görüntü bellek alanlarını dump etmek, komut duraklarını set etmek ve
gerçek bir konsoldan kontrol edilen diğer fonksiyonları gerçekleĢtirmek için
kullanılır.
169
Bir görüntü makinası programları, gerçek bir makinada çalıĢıyormuĢ gibi
çalıĢtırır. Görüntü makinası opratörü ile bir terminal aracığı ile iletiĢim kurar. Bir
görüntü makinasında çalıĢan iĢlemler CP tarafından değil görüntü makinasında çalıĢan
iĢletim sistemi tarafından kontrol edilir. Görüntü makinaları birbirinden bağımsız
olarak çalıĢır ve aradaki uyuĢmazlıklar CP tarafından çözülür. Bir görüntü
makinasında çalıĢan iĢletim sistemleri, bellek yönetimi, processor scheduling, g/ç
kontrolü, kullanıcıları birbirinden korunması, iĢletim sisteminin kullanıcılardan
korunması, spooling, multiprogramming, iĢ ve iĢlem kontrolü ve hata yakalama gibi
bütün fonksiyonlarını içerir.
VM yarattığı görüntü makinalarının herhangi birinde çalıĢabilir (ġekil-84).
Bu çok kullanıĢlıdır, örneğin CP'nin debug edilmesini sağlar.
MVS
Görüntü
370
DOS/VS MVS
Görüntü
CP
Görüntü Görüntü
370
370
Görüntü
370
Görüntü
....
Görüntü
370
Donanımı
CP
Gerçek
370
Gerçek
Donanım
ġekil-84. VM Tarafından Yaratılan Görüntü Makinasında VM'i ÇalıĢtırma
19.1. Tarihçe
1940'lı ve 1950'li yıllarda, bilgisayar sistemleri tek kullanıcılı idi. Bilgisayar
kullanıcısı, gerçek makinanın konsolunda, görünür makinanın tüm olanakları ve
kullanıcıya uygunluğu ile otururdu. Bir iĢ iĢletimi, günümüzün kiĢisel bilgisayarı
gibiydi. (Eğer makina bir cevaba ihtiyaç duyar ve kullanıcı bir süre onu düĢünürse,
makina boĢ duruma düĢer.). Gerçek fark fiyattı ve fiyatları günümüz bilgisayarının
binlerce katıydı.
170
Bir kullanıcıya ayrılmıĢ tam makina kavramı VM'le simule edilmiĢtir. VM'deki
bir kullanıcı, gerçek makinanın eĢitini görür, bu bakıĢ geleneksel interaktif sistemlerin
kullanıcıya sağladığından çok farklıdır.
Batch multiprogramlama sistemleri pahalı hesaplama kaynaklar olmadan
daha iyi kullanmak için geliĢtirildi. Farklı kullanıcılar için bilgisayara komut yollamak
imkasızlaĢtı.
1960' ların baĢında, MIT'de bir grup, klavye terminallerinde oturan
kullanıcılara, makinanın hesaplama gücünü idare etmeye izin veren CTSS zaman
paylaĢımlı sistemi geliĢtirdi. CTSS program editleme ve debuglama yapan
interaktif
kullanıcılara cevap verirken, bilgisayar meĢguliyetini saklamak için
geleneksel batch gidiĢini uygular CTSS ile sağlanan hesaplama olanakları VM için
sağlananlara ve günümüz kiĢisel bilgisayarlarına benzer. Yani bilgisayardaki yüksek
interaktif parçalar, büyük sayıdaki önemsiz ihtiyaçlara hızlı cevap verir.
Bundan dolayı CTSS, interaktif hesaplama çok büyük oranda popüler oldu.
Milyonlarca kiĢi, her gün iĢlerinde, evlerini yönetmede, finansta ve yeniden yaratmada
interaktif hesaplama olanaklarını kullanırlar.
Günümüz kiĢisel bilgisayarları, 30 yıl önce atalarının yaptığı gibi tüm
makinanın hazır iĢlemini sağlar. Fakat kiĢisel bilgisayarların bilgiye ihtiyacı olan
ülke olarak ulusal ve ulslararası networklara bağlanabilmesi büyük farktı.
CP/CMS 1964'te deneysel bir sistem olarak baĢladı.CP/CMS IBM Sistem /360
bilgisayarları üzerine kurulu ikinci kuĢak bir time-sharing sistemiydi. Esasen, IBM
Cambridge Scientific Center'de yerel bir kullanım için geliĢtirildi. Kısa zamanda diğer
iĢletim sistemlerinin performanslarını değerlendiren bir alet oldu.
CP-40 ve CMS'i içeren ilk iĢlemsel versiyonu 1966'da gözüktü. Bu parçalar,
Dinamik Adres Çevirim donanımıyla yeni birleĢtirilmiĢ IBM 360/40 üzerinde
çalıĢtırmak için tasarlanmıĢtı. Bu sıralarda IBM onun daha güçlüsü olan 360/65'i
geliĢtirdi. Yeni sistem, 360/67 Dinamik Adres Çevirim donanımıyla birleĢtirildi
TSS/360 diye anılan genel amaçlı time-sharing, multiprogramming
bilgisayar
olaylarına esas sağlamak için düĢünüldü. CP/CMS üzerinde çalıĢmalardan bağısız
olarak yapılan TSS,bir çok zorluklarl karĢı karĢıya geldi. Bu sırada CP/CMS baĢarılı
olarak 360/67 Ģeklini aldı ve TSS'nin yerine geçti. VM/370, IBM 370 serilerinin
görüntü bellek modelleri için 1972 yılında kullanılabilir oldu. Bugün 2500 büyük
ölçekli VM sistemleri üzerinde iĢletiliyor ve sayı gittikçe büyüyor.
MIT'te 1974' e doğru baĢarı ile kulanılan CTSS CP/CMS'in tasarımına çok etki
etti. CTSS tasrım grubu, ticari baĢarı kazanamayan Multics sistemini tasarlamaya
gittiler.CP/CMS tasarımcıları CTSS'i tasarlamak ve değiĢtirmenin zor olduğunu
anladılar. Daha modüler bir
yaklaĢım aradılar ve CP ve CMS'deki iĢletim
sisteminin kullanıcı destekli kısmından kaynak yönetim kısmını ayırdılar. CP her
kullanıcıya dolu makinaya tam geçiĢi veren ayrı hesaplama birimleri sağlar. CMS,
görüntü makina yaratılan CP'de, bir kullanıcılı interaktif sistem olarak çalıĢır. CP'nin
171
tasarımında yapılan bir çok bilimsel karar görüntü makinayı gerçek makina yapmaktı.
360 ailesi kavramı 360 programları için uzun hayan süresini yaratacaktır. Daha çok
güce ihtiyaç duyan kullanıcılar, daha çok bellek, alet ve CPU hızıyla uyumlu bir
sistem ailesi çıkaracaktı.360'dan yapısal olarak farklı VM üretme kararı CP/CMS
sisteminin baĢarısızlığı ile sonuçlandırılacaktı. DüĢünce baĢarılı oldu ve VM, IBM
için 1980'lerin baĢlıca iĢletim sistemi olabilecek duruma gedi.
20. Kontrol Programı (Control Program)
CP, VM/370'in değiĢik iĢletim sistemlerinin çalıĢtığı görüntü makinaları yaratan
kısmıdır. CP, gerçek makinanın denetleyicisi durumunda çalıĢtığından, öncelikli tüm
komutları iĢleyebilir. CP belli bir görüntü makinasını görevlendirildiği zaman, bu
görüntü makinası, gerçek makina üzerinde çalıĢır. Yalnızca bir gerçek iĢlemci vardır
(tek iĢlem olduğunu varsayarak) ve bu makina iki durumda olabilir: denetim, problem.
Fakat bir çok görüntü makinası vardır. CP, herbir görüntü makinası için görüntü
yazmaçları ve görüntü durum kelimesi (virtiual state word) içeren bir ana kontrol bloğu
tutar. Görüntü durum kelimesi, görüntü makinasının o anki durumunu ve görüntü komut
sayacını gösterir.
Görüntü makinası da iki durumda olabilir:
- Görüntü denetim
- Görüntü program.
Gerçek makina çalıĢmasını denetim ve problem durumları sırasında seçer.
Gerçek makina konsolu baĢındaki bir kullanıcı diğer iĢletim sistemi kullanıcılarından
farklı birĢey hissetmez. Bununla birlikte CP, herbir görüntü makinasının hangi durumda
olduğunu izler. CP bunu o kadar etkin bir Ģekilde yapar ki, görüntü makinasındaki
iĢletim sistemi CP'nin görüntü makinasının gerçek problem durununda
çalıp
çalıĢmadığını belirleyen komutları bile uygulayamaz. CP bir görüntü makinasını
görevlendirdiğinde, görüntü makinası gerçek komutları gerçek makina üzerinde iĢletir
CP kontrolü çeĢitli kesintiler (interrupt) ile sağlar. Birçok kesinti iĢletim sistemi
tarafından öncelikli kabul edilen komutlar iĢletilmeye çalıĢıldığında oluĢur. Fakat
görüntü makinası gerçek problem durumunda çalıĢmak için yapıldığından, her öncelikli
komut çalıĢtırıldığında kesinti oluĢur. Bundan dolayı proğram kesintileri CP ile
çalıĢan bir görüntü makinası arasında arayüzleme yapmak için anahtar görevi
yapar.
Bir görüntü makinası, proğram dıĢı bir kesinti oluĢtuğunda CP kontrolu ele
alır ve kesintinin nedenini belirler. Görüntü makinası görüntü problem durumunda
çalıĢıyor olabilir. O halde CP gerçek problem kesintisini doğrudan görüntü
makinasına gönderir. Görüntü makinası daha sonra bu kesintiyi kendi kesinti iĢleme
yardımları ile iĢler.
Bununla birlikte görüntü, makinası görüntü denetleme durumunda çalıĢıyorsa,
öncelikli komut iĢlemesini sağlar. Önce görüntü makinasının ne yapmaya çalıĢtığını
belirler. g/ç iĢlemi yapılmaya çalıĢılıyorsa, CP görüntü ve gerçek aygıtlar arasında
172
gerekli haritalama (mapping) iĢlemini yapar. Eğer diske g/ç yapılıyor ise, CP görüntü
iĢ adreslerini gerçek iĢ adreslerine dönüĢtürür. Daha sonra, görüntü g/ç isteğine karĢılık
gelen gerçek g/ç iĢlemini yürütür ve sanki g/ç'ı kendisi baĢlatmıĢ gibi kontrolu, iĢlemi
devam ettirecek görüntü makinasının iĢletim sistemine devreder.
Bir g/ç iĢlemi tamamlandığında CP tamamlama kesintisini alır ve o g/ç iĢlemini
isteyen görüntü makinası iĢletim sistemine devreder. Bu görüntü makinası iĢletim
sistemine gerçek bir donanımın kendi g/ç iĢlemiymiĢ gibi görünür.
21. Demand-Paging (Ġstenebilir Sayfalama)
CP, bilgisayar sisteminde demand-paging ve dinamik adres çevirimi yapabilen
donanım ile çalıĢır. Gerçek bellek küçük bir çekirdek bölümü hariç tamamen sayfalanır.
Bu küçük çekirdek bölümü, bellekte değiĢmeden kalır. ġekil-85'te üç kullanıcı
(CMSA,CMSB,CMSC) ve iki OS/VS1 görüntü makinaları (VS1A,VS1B) çalıĢtıran bir
VM sisteminde gerçek bir belleğin nasıl görülebileceğini göstermektedir.
CP'nin Sayfalanamaz Kısmı
CP'nin Sayfalanabilir Kısımları
VS1A CMSB CMSC VS1A VS1B
çekirdek
bölme 2 bölme 1
CMSA VS1A CMSC VS1B VS1B
çekirdek
çekirdek çekirdek
VS1A
CMSB CMSC VS1B
çekirdek
çekirdek
CMSA CMSC CMSC VS1B
bölme 2
VS1A VS1B
CMSA CMSB
bölme 1 bölme 2
VS1A VS1B
CMSB CMSA
bölme 1 bölme 2
ġekil-85. VM Altında Gerçek Bellek Kullanımı
Bunun sonuçları oldukça ilginçtir. OS/MVT ve OS/MFT gibi gerçek bellek
iĢletim sistemlerinin VM altındaki performansları gerçek bir makinedekinden oldukça
farklıdır. CP bu iĢletim sistemlerindeki belleği sayfalar. Fakat, zamanlamadaki
gecikmeler, VM'in gerçek bellek ortamlarında çalıĢmak için tasarlanan belli iĢleri
çalıĢmadaki kullanıĢlılığını ortadan kaldırır.
173
DOS/VS ve MVS gibi görüntü bellek iĢletim sistemleri VM altında
çalıĢtırıldığında daha önemli problemler ortaya çıkmaktadır. Bu sistemler sayfalamayı
iki düzeyde yapar.
* Görüntü makinası tarafından baĢlatılan sayfalama,
* CP tarafından baĢlatılan sayfalama.
Görüntü makinası tarafından baĢlatılan sayfalama CP tarafından normal G/Ç
olarak ele alınır.
CP atrafından baĢlatılan sayfalama görüntü makinasına mantıksal olrak Ģeffaftır.
Performans sayfalama sistemlerinde daima dikkate alınır birden çok sayfalama
seviyesi nedeniyle VM sistemlerinde performans daha önemlidir.
* Bir görüntü makinası, "görüntü eĢittir gerçek" moduna çalıĢmak üzere
hazırlanmıĢtır.
* Tek baĢına bir sayfa çerçevesi gerçek bellleğe kilitlenebilir.
* Gereksiz sayfalamalar görüntü makinelerinde “handshaking” denilen ve
görüntü makinesinin CP ile arayüzlemesine izin verip CP mekanizmalarının
avantajlarını kullandıran bir teknik ile ortadan kaldırılabilir.
Handshsking tekniği kulanıcıların yararı için karar veren kaynak ayırma
mekanizmalarına izin verdiği için caziptir. Ġlk iki seçenek sistemin çalıĢmasını çok
yavaĢlatabilir ve kapasitesini büyük ölçüde sınırlayabilir. Bütün bu seçenekler dikatlice
incelenmelidir.
22. Minidiskler
Bir DASD(Doğrudan eriĢim bellek aygıtı) volume'u özel bir görüntü makinesine
adanabilir veya birden fazla görüntü makinesi arasında paylaĢılabilir.
Bir tek DASD, CP tarafından, herbiri baĢka bir görüntü makinesine ayrılmıĢ olan
minidisklere bölünebilir. Minidiskler disklerin alt kümesi olarak düĢünülebilirler.
Herbiri silindirlerden oluĢur, görüntü makinesi iĢletim sistemi tarafından bütün bir
fiziksel disk olarak kullanılır. Disklerden daha küçük kapasiteye sahaiptirler. CPP
minidisklerin gerçek disklere haritalanması iĢlemini yürütür. Minidisklerin boĢ alanları
minidiskin atanmıĢ olduğu görüntü makinesinde çalıĢan iĢletim sistemi tarafından
yönetilir. CP Görüntü makinesinin kendi minidiskinin sınırları dıĢındaki bir disk alanına
ulaĢmasını önler. Minidisklerin paylaĢılması mümkündür, fakat dikkatli bir Ģekilde
kontrol edilmesi gerekir. ġekil-86'da örnek bir disk üzerinde minidiskler görülmektedir.
174
Gerçek
silindir
numaraları 0
1
Gerçek
0 silindir
numaraları
0
REALID
MINI 01
36
0
14
0
37
38
MINI 02
52
53
MINI 03
113
114
60
0
MINI 04
119
120
5
0
ġekil-86. Gerçek Disk Üzerinde Minidiskler. Her Minidisk Görüntü Silindir Sıfıra
Ayrılım.
23. Konsol Yönetimi
CP, her görüntü makinesi için bir görüntü konsolu sağlar. Böylece
terminallerdeki kullanıcılar sanki gerçek makineye karĢılık gelen tam bir fiziksel
konsolları varmıĢ gibi kendi görüntü makinelerini kontrol ederler. Bu kullanıcılara
zaman paylaĢımlı sistemlerdekinden çok daha fazla etkinlik sağlar. Kullanıcıların
terminallerden kullanabileceği bazı CP komutları ġekil-87'de özetlenmiĢtir.
ADDSTOP görüntü bellekte bir komut adres durma yeri belirler.
BEGIN görüntü makinesindeki iĢlemi yeniden
sistemlerindeki eĢiti START tuĢuna basmaktır).
baĢlatır
(gerçek
bilgisayar
DETACH belirtilen bir aygıtı görüntü makinesinden ayırır.
DISPLAY görüntü makinesinin belirtilen yazmaçlarını veya görüntü bellek içeriklerini
görüntüler.
175
EXTERNAL bir disk kesintiye neden olur.
LINK eğer bölüĢümlü olarak tanımlanmıĢ ve doğru Ģifre girilmiĢse belirtilen görüntü
DASD'i görüntü makinesine bağlar.
QUERY açılma mesajları, spool kütükleri sayısı gibi belli sistem bilgilerini görüntüler.
READY bir görüntü makinesinden gelen aygıt sonu kesintisini simule eder.
SET hata mesajı seviyesinin görüntülenip görüntülenmeeyeceği ya da terminal giriĢ
için VM satır düzenleme miktarını belirleyen bazı sistem değerlerini değiĢtirir.
SPOOL spooling için kullanılan bir yada daha fazla görüntü birim kayıt aygıtları için
spooling kontrol seçeneklerini (kopyaların sayısı gibi) değiĢtirir.
STORE verileri görüntü makinesi yazmaçları yada görüntü belleğe yerleĢtirir.
TERMINAL kullanıcıya VM mantıksal editleme sembollerini ve terminalden yada
terminale yapılan G/Ç iĢleminin mantıksal satır uzunluğunu tanımlamasını sağlar.
ġekil-87. Bazı CP komutları
24. CP Kullanıcı Öncelik Sınıfları
Büyük bilgisayar ortamları (örneğin VM) çalıĢırken değiĢik kullanıcıların sistem
ile iletiĢimi için değiĢik gerksinimleri vardır. Bu kullanıcıların bir kısmı uygulama
kullanıcılarıdırlar. Diğerleri sistemin iĢletimi, yönetimi ve günlenmesi ile daha çok
ilgilidirler. Bukullanıcıların tamamı iĢletim sisteminin tüm özelliklerine gerek duymaz.
Gerçekte, sisteme zarar vermemeleri için, kullanıcıların bir kısmının bazı sistem
özelliklerine ulaĢması engellenmelidir. VM, çeĢitli grupları tanımlamak için kullanıcı
öncelik sınıfları Ģeması kullanılır. CP komutları bu öncelik sınıfları ile ilgilidir.
Kullanımına izin verilmeyen bir komut iĢletilmeye çalıĢıldığında, kullanıcının komuta
ulaĢımı engellenir. CP kullanıcı öncelik sınıfları Ģekil-88'de özetlenmiĢtir.
176
SINIF
KULLANICI
ĠġLEV
----------------------------------------------------------------------------------------------------A
Sistem operatörü
VM'nin durumunu, mesajlarını,
performans seçeneklerini kontrol
eder
B
Sistem kaynak Oprt:
A ve D tarafından kontrol edilenler hariç (örneğin B kullanıcısı
belli bir kullanıcıyı bir kanaldan
çıkarabilir) bütün gerçek VM kaynaklarını kontrol eder.
C
Sistem programcısı
Diğer kullanıcı sınıfları tarafıdan
kontrol edilmeyen fonksiyonları
günleyebilir.
D
Spooling operatör
Spooling verilerini ve belli birim
kayıt fonksiyonlarını (yazı tek veya
çift boĢluk ayarlama) kontrol eder.
E
Sistem analisti
VM bellek alanındaki verileri
inceleyebilir
veya
saklayabilir.
F
Gerçek G/Ç aygıtlarına ilĢkin
verilere eriĢilebilir. F sınıfı
kullanıcı
sistem hata kayıtlarındaki
verileri
çıkarabilir.
G
Genel kullanıcı
Kullanıcının görüntü makinesi
iĢletimine (örneğin bir görüntü
makinesini baĢlatmak) bağlı olarak
değiĢik kontrol fonksiyonlarını
gerçekleĢtirebilir.
H
AyrılmıĢ
IBM kullanımı için ayrılmıĢtır.
Diğer
Diğer kullanıcılar
VM eriĢebilirler.
ġekil-88. Kullanıcı Öncelik Sınıfları
25. VM Directory'si
VM'e eriĢim, VM directory'sindeki bilgi vasıtasıyla kontrol edilir. VM
directory'si belli bir görüntü sistem üzerinde çalıĢmasına izin verilmiĢ bütün potasiyel
görüntü makinelerinin tanımlarını içeren bir kütüktür. U directory, her kullanıcı için bir
kullanıcı kimliği, password, öncelik sınıfı ve kullanıcının görüntü makinesini
tanımlayan çeĢitli bilgileri içerir.
ġekil-89'de örnek bir VM directory'si görülmektedir. Kullanıcının kimliği
(identification) ve password'u VIRT1'dır. Bu görüntü makina için maksimum 1M'lik
görüntü bellek olmak üzere toplam 512K-byte'lik bir görüntü bellek tahsis edilmiĢtir.
Hesap numarası S5'tir.Konsol, 009 görüntü fiziksel aygıt adresinde olup 3215 türüde bir
177
aygıttır. Bu görüntü makine spool edilmiĢ birim aygıtları kullanır. Bu aygıtların görüntü
fiziksel adresleri 00C'de bir 2540 reader'i, 00D'de bir 2540 punch'i ve 00E'de bir 1403
yazıcısıdır.Bu aygıtların her biri A spool çıktı sınıfına sahiptir.Görüntü fiziksel aygıt
adresi 191'e bir adet 3330 minidiski atanmıĢtır. LINK sözcüğü, bu görüntü makinanın
baĢka bir görüntü makinaya ait bir minidiske sadece okunur olarak eriĢilebileceğini
gösterir.
USER VIRT1 VIRT1 512K 1M G
ACCOUNT S5 SYSPRG
CONSOLE 009 3215
SPOOL 00C 2540 READER A
SPOOL 00D 2540 PUNCH A
SPOOL 00E 1403 A
MDISK 191 3330 001 001 CPR6L1 R
LINK MAINT 194 194 RR
ġekil- 89. Örnek VM directory Elemanları
VM/370 online
logon smith
ENTER PASSWORD
LOGON AT 10:02:35 ON FRIDAY 05/27/8
ipl cms
ġekil- 90. VM/370 Makinasına Logon Olunması ve CMS'in Yüklenmesi
Geçerli bir directory elemanlarına sahip kullanıcılar, ġekil 90'da gösterildiği
Ģekilde VM'e logon olabilirler. Kullanıcı, kullanıcı kimliği (user identification) yazar.
Sistem bu kimliğin geçerli olup olmadığını kontrol ettikten sonra kullanıcının
paassword'unu girmesini ister. Kullanıcı bundan sonra password'u girer. (Password
gizlilik nedeniyle sistem tarafından maskelenir, yani görüntülenmez). Password'un
doğru olduğundan emin olmak için, directory kontrol edilir. Sisteme logon olduktan
sonra kullanıcı, desteklenen iĢletim sistemlerinden herhangi birini çalıĢtırabilir.
VM bir güvenlik bildirme seçeneği (Security Journaling Option)'ne sahiptir. Bu
seçeneğin sistem üretildiğinde belirtilmesi gerekir. Bu opsiyon yürürlükte iken, baĢarısız
logon denemeleri kayıt edilir ve sistem yöneticisine tarih, saat, terminel kullanıcı kimliği
ve söz konusu password'u belgeleyen mesajlar gönderilir. BaĢarısız logon denemelerinin
çoğunluğu, kullanıcının yanlıĢ yazılımında kaynaklanmaktadır. Bu nedenle, sisteme
tekrar tekrar birbirine benzer password'lerle sızma giriĢimleri tespit edilecektir.
26. CMS (Conversational Monitor System)
178
BaĢlangıçta, CMS Cambridge Monitör System'in kısaltılmıĢ haliydi. Fakat son
zamanlarda Conversational Monitör System için kullanılmaya baĢlandı. CMS,
kullanıcıya gerçek bir makina gibi görünüp aslında CP tarafından yaratılmıĢ bir görüntü
makina olan seye tam bir eriĢim veren diske-yönelik (disk oriented) bir iĢletim
sistemidir. CMS, CTSS'dekilere oldukça benzer fonksiynlara sahip tek kullanıcılı bir
sistemdir. CMS, ilk olarak faal duruma geçtiğinde makinayı sistem konsolundan idare
ednen bir kullanıcıya hizmet veren gerçek bir 360'ta çalıĢtı. Sonunda, CP kullanılmaya
baĢlandığında, CP'nin yarattığı bir görüntü makinada çalıĢması için CMS yeni baĢtan
yazıldı. CMS'in mevcut uyarlamaları çıplak makina üzeride çalıĢır.
Görüntü makinalar arasında verilerin paylaĢımı, birden çok görüntü makinanın
ortak disklere eriĢimi sağlayan CP tarafından kontrol edilir. Bunna ilaveten payalaĢım,
veri kütüklerinin görüntü makinalar arasında iletiĢimi ilede sağlanır.
Kullanıcının kullanabildiği CMS komutlarının tümü disk kütüklerinde saklı olup
gerçekte sistemin bir parçası değildirler. Bu ise, komut kütükleri ekleyerek, çıkarak veya
değiĢtirerek kullanıcıların kendi görüntü makinalarının komut takımını kendi
ihtiyaçlarına göre değiĢtirmelerini kolaylaĢtırır.
CMS, kullanıcıya güçlü program geliĢtirme olanakları verir. CMS kullanıcısı,
kendine özel (dedicated) bir görüntü makina ile karĢı karĢıyadır (ġekil-91). VM, birçok
birbirinden ayrı CMS görüntü makinalarını destekleyerek çok kullanıcılı bir zaman
paylaĢımlı (time-sharing) ortam sağlar.
Kullanıcı CMS ile bir terminal vasıtasıyla ve Görev Kontrol Deyimleri ile
ietiĢim kurar. CMS kullanıcıya yakın (user friendly) bir arayüz sunar. Önemli hata
mesajlarını doğrudan interaktif kullanıcıya vererek hataların anında düzeltilmesine
imkan verir.
179
kullanıcı
diski
okuma/yazma
320K
görüntü
konsolu 128K
0
CMS çekirdek
Sistem
diski
read only
görüntü deposu
görüntü
teyp
sürücü
görüntü
teyp
sürücü
görüntü
teyp
sürücü
görüntü
okuyucu
görüntü
punch
görüntü
yazıcı
ġekil-91. CMS Kullanıcısı Tarafından Görünen AdanmıĢ Görüntü Makinası
180
27. RCSC (Remote Spooling Communications System)
RCSC (Remote SPOOLING (simultaneous peripherals operations online) And
Communications System) bilgisayarlar ve haberleĢme ağlarındaki uzak iĢ istasyonları
arasında veri kütüklerinin transferine imkan verir (ġekil-92). CP yaratılıĢlı bir görsel
makinada çalıĢır ve kütük taĢıması için haberleĢme bağları ve birim kayıt elemenları
kullanılır
Bilgisayar sistemleri ve uzak iĢ istasyonları arsında, daha geleneksel iletimde
olduğu gibi aynı gerçel aygıtta görsel makinalar arası kütük transferi için, uygun aracı
hazırlar.
CP, tek baĢına görsel makinalar arasindaki kütükleri tek gerçel makina üzerinden
geçirir. Her köĢesinde bir görsel makinanın olduğu, yıldız ağı içinde merkez ususu gibi
çalıĢır. Bir kütüğü diğĢerine göndermek isteyen görsel aygıt, onu hedef makinaya
geçiĢrmesi için, CP'ye yollar. Kütükler her görsel makinanın görsel kart okuyucusu ve
delicisini kullanarak iletir.
RCSC iletiĢim ekipmanlarına bağlı bir görsel makinada çalıĢır. Her gerçel
bilgisayar sisteminin tek tanımlayıcısı vardır. BaĢka bilgisayara iletmek üzere, RCSC bir
kütüğü bir sonraki bilgisayardaki RCSC yollar ve hedefine ulaĢana kadar bir sonraki ne
IBM içinde , RCSC, 400 bilgisayar sistemi üzerinden 50000 kullanıcıyı adreslemede
kullanılır.
CP
CP
Makara
Sistemi
VM
görüntü
makina
OS/360
hasp
batch
işlemci
RSCS
görüntü
makina
Programlanabilir
Uzak
uzak
istasyon
İstasyonlar
Programlanamaz
uzak
istasyon
OS/VS1
Programlanabilir
uzak
istasyon
ġekil-92. Bir VM / RSCS TeleiĢlem Ünitesi
181
CMS
28. VM' in Gücü
VM hesaplama uygulamalarında çeĢitlilik sağlar. Bir gerçel bilgisayarı görsel
bigisayar durumuna getirir ve her görsel bilgisayar farklı iĢletim sistemi sağlayabilir.
VM'i çalıĢtıran bir düzen böykelikle, farklı yetekler sunan farklı iĢletim sitemleriyle, ayrı
ayrı birçok bilgisayar sistemini çalıĢtırıyor izlenimini yaratır.
VM, üretim iĢi devam ederken, yeni iletim sisteminin test edilmesine izin verir.
Programların yeni formata dönüĢtürülmesi ve bu yeni programların testi, tertibatın
süregelen olağan iĢletimi ile eĢzamanlı gerçekleĢebilir. CMS yeni formatlara geçiĢi
mümkün kılar.
Çoğu aktif düzenler, sabit olarak öerilen, test ve tesis edilen değiĢikliklerle birer
dinamik bütülüktür. VM bu aktivitelere, süregelen iĢlemlerle eĢzamanlı olmayı mümkün
kılar.
Bazen, belli uygulamalar sistem tertibatında varolan farklı bir iĢletim sisteminin
olurluğunu gerektirir. VM tüm diğer iĢletim unsurlarını durdurmaya ihtiyaç
duymaksızın, uygun iĢletim sistemi altında uygulama çalıĢtırmaya imkan verir.
VM'in merak uyandıran bir baĢka uygulamasıda, aynı iĢletim sisteminin birden
fazla kopyesini çalıĢtırmasıdır. Bazı iĢletim sistemleri, çalıĢabilecek kullanıcı sayısını
kısıtlar. VM'i geniĢleterek, belli bir iĢletim sistenmini (daha çok kullanıcı ile)
sürebilmeyi arzu eden tertibat, bu ĠĢletim Sistemi’nin birçok kopyasını çalıĢtırabilir ve
böylelikle bir anda çalıĢabilecek kullanıcı sayısını iki, üç vs. katına çıkarabilir.
VM 1370, tabii ki disk veya teyp hacimleri takılı olmaksızın, ihmal edilmiĢ
olarak isteyebilen güvenilir çevre donanımını sağlar.1978 Ģubatında New Englınd
Ģiddetli bir tipi geçirmiĢti. Tüm Massachusetts eyaleti tam anlamıyla evlere hapsoldular.
Sadece acil yardım araçları yollarda bulunmaya izinliydiler. Bu dönemde IBM'in
Cambridge Fen merkezindeki VM/370 sistem, operatörsüz kilitli bir bilgisayar
odasında, bir hafta süreyle, arlıksız fonksiyonunu yerine getirdi. Sistem özel görevli
operatör tarafından uzak bir terminalden gözetleniyordu.
29. VM/370'in GeliĢimi
Tanıtımından buyana VM/370geliĢmeye devam etmiĢtir. Görsel makinalar arası
haberleĢme daha popüler olmuĢ ve daha çok uygulama sistemleri, görsel cihaz çevrecisi
Halley etalin yapısal özelliklerinden yararlanmaya eğilim göstermiĢler. (Ho79) VM
çevrecilerindeki çoklu iĢletim sistemini tartıĢ.
30. Performansı Etkileyen Faktörler
VM/370'in performansını birçok faktör etkiler
* Kullanılan bilgisayar sistemi
* IĢlemekte olan görütü makinelerinin sayısı
182
* Görüntü makinelerinde çalıĢan iĢletim sistemleri
* Görüntü makinelerindeki iĢ yüklerininyapısı
* Kullanılan kanal sayısı
* Kanalların tipi (blok multiplexer ya da selector)
* Kullanılan gerçek bellek kapasitesi
* Görüntü makine yardım özelliğinin kullanımı
* VM uzantılı kontrol program desteğinin kullanımı
CMS CP tarafından yönetilen görüntü makinelerınde etkin bir Ģekilde çalıĢır. Bir
VM sistemi, MVS görüntü makinelerinden daha çok CMS görüntü makinesi
çalıĢtırılabilir. Bundan dolayı bir donanım konfigrasyonunu sadece desteklediği görüntü
makinesi sayısına göre sınıflamak zordur.
31. Görüntü Makine Yardım Özelliği
Görüntü makine yardım özelliği VM tesisatına uygun bir performansislah
opsiyonudur. Donanım ve yazılım birimlerinin ikisine birden sahiptir. Görüntü bellek
iĢletim sistemleri OS/VS1 ve DOS/VS, VM 370'in kontrolü altındayken problem
durumunda iĢler. Bu iĢletim sistemleri büyük satırda ayrıcalıklı komut kullanırlar ve
SCV'ler VM teĢebbüsleri için ihtiyaç dutulan interruptları (kesinti) üretir. Normal olarak
bu kesintiler yazılım rutinleri tarafından dağıtılır. Fakat VM görüntü makine yardım
özelliği ile donanım bilimsel performans islahında sonuçlanan bu interruptların çoğunu
durdurur veya dağıtır.
32. Uzantılı Kontrol Program Destek Özelliği
Uzantılı kontrol program destek özelliği yayılmıĢ görüntü makine yardımını,
görüntü aralık zamanlayıcısı yardımını sağlar.
GeniĢletilmiĢ görüntü makine yardımı daha öncelikli komutların donanımsal
emilasyonunu içerir. Kullanımı doğrudan donanım emülasyoyla dağıtılan kesintilerin
yüzdesini arttırır.
CP yardımı, görüntü makine g/ç iĢlemleri, bellek yönetimi, sayfa yönetimi,
öncelikli komut yönetimi dahil sık sık kullanılan daha birçok kısımları için yardım
sağlar.
Görüntü aralık zamanlayıcısı yardımı her görüntü makine için aralık
zamanlayıcısının donanımsal günlenmesini sağlar. Bu özellik olmasaydı günlenme
iĢlemi yazılımla yapılacaktı. Donanım zamanlayıcı değerlerinin daha güvenli olmasını
sağlar.
33. Performans Ölçme ve Analiz
VM kontrol programı, sistem performansını ölçen ve rapor eden iki komutun
kullanımını sağlar. VM'deki bu özelliklerin birleĢmesi, tasarıcının performans izlemeye
183
verdiği öneme ve kullanıcıların sistemlerinin ne kadar iyi çalıĢtığını bilme isteğine
cevap verir.
MONITOR komutu teyp'ki performans ölçme verilerini sonraki analizler için
toparlar. INDICATE komutu o andaki performans bilgilerini kullanıcı terminalinde
gösterir.
VM'in CP çalıĢırken sistem performansını izlemek için hazır imkanları vardır.
CMNS, çok küçük bir taĢma ile doğrudan CP altında çalıĢması için tasarımlanmıĢtır.
Fakat diğer görüntü makineleri CP altında çalıĢırken önemli bir taĢmadan Ģikayatçi
olmaktadır ve tasarımcılar bu konudan bahsetmektedirler. Bu taĢmayı azaltmak için
yıllar boyunca VM üzerinde birtakım iyileĢtirmeler yapılmıĢtır.
CP, sayfalı olmayan OS/MFT ve OS/MVT gibi sistemleri bile sayfalar. Sayfasız
gerçek bellek ortamları için tasarlanmıĢ bazı programlar, sayfalı bir ortamla ilgili
gecikmelerin olmadığı çok yüksek bir performans ister. VM kullanıcılarının elindeki bir
seçenek ise bir görüntü makinasının virtual equals real mode diye adlandırılan bir
modda çalıĢmasını sağlar böylece o görüntü makinesinin gerçek belleği sayfalanmaz.
Prosedur kodlarını farklı görüntü makinaları arasında paylaĢmak mümkündür.
Bu daha iyi bellek kullanımını sağlar.
34. VM : IBM'in 1980'li Yıllar Ġçin Büyük Ölçek ĠĢletim Sistemleri
Bu bölümde, VM'in gelecek onlu yıllarda artan bir önem kazanacağı durumu
tartıĢır. Bunun muhtemelen böyle olacağını destekleyen birçok sebep vardır.
Günümüzde büyük Ģirketlerin, birkaç yılın yedek programlarına sahip olmaları
yaygın olmayan bir Ģey değildir. Unulmaktadır ki 1980'lerin ortalarından sonlarına
doğru, yetiĢtirilen programcı sayısı talebin %50 eksiğine düĢecektir. Açıkçası, 1980'lerin
programcı gereksinimler ile karĢılaĢacaksak, programcı üretgenleğini arttırmak
zorundayız. 1960'ların keĢfi olan etkileĢimli program geliĢtirme, programcı üretgenliğini
oldukça arttırmıĢtır. Bunun için etkileĢimli program geliĢtirmeyi kolaylaĢtıran iĢletim
sistemleri 1980'lerde önem kazanacaktır.
BM'in büyük öncelikli bilgisayarları için olan ve etkileĢimli iĢletim sistemleri
arasında IBM için çalıĢan iki rakip, MVS in TSO (zaman paylaĢım opsiyonu) su ve
VM'dir. Hiçbir Ģüpheye gerek kalmaksızın, hem sağlanan yetenekler açısından hemde
saflık performansı açısından VM, en iyi iĢletim sistemidir. Herhangi bir bilgisayar
sisteminde VM'in MVS'in desteklediğinin iki katı kullanıcıyı destekleyebilir olması
oldukça sıklıkla karĢılaĢılan bir durumdur.
MVS yıllarca, IBM'in düzey deste iĢlem iĢletim sistemi olmuĢtur ve olmaktadır.
IBM kullanıcıları, MVS'e kıymetli taahhütlerde bulunmuĢlardır ve bu taahhütler ihmal
edilemez. IBM aslında, kendi MVS kullanıcılarının büyük çoğunluğunu tamamıyla
farklı bir iĢletim sistemine değiĢtirmesi için zorlayamaz. Burada VM'in çok yönlülüğü
ortaya çıkmaktadır. Çünkü MVS, VM'in altında çalıĢabilir. Bunun için MVS'e emanet
184
edilen bir tertibat VM altında, VM'nin önemli etkileĢim yeteneklerini sağlarken onu
çalıĢtırabilir. Tertibat VM'yi çalıĢtıracak ve VM'yi altında VMS'i ve birçok CMS
görüntü makinalarını çalıĢtıracaktır.
IBM'in kendi küçük tertibatları için disk iĢletim sistemini (DOS) geliĢtirmiĢtir.
DOS, MVS kıyaslandığında ona oranla basit sistemdir. O, kuvvetli deste iĢlem
yeteneklerin, fakat zayıf karĢılıklı etkileĢim yeteneklerine sahiptir. Yıllar boyunca, DOS
kullanıcıları genellikle daha fazla yetenek için, MVS'e dönmeye karĢı direnmiĢlerdir.
Bunun yerine onlar,bu ilave yeteneklerin DOS'ta sağlanması için, IBM üzerinde
hissedilir derecede baskı yapmıĢlardır. Fakat geliĢen bir tertibat olarak, DOS'unda
etkinliğinin bir sınırı vardır. Bunun için bir çok DOS kullanıcısı istemeden MVS'e
dönmüĢlerdir. Çoğunlukla bir küçük kopya ya da sancılı bir tecrübeyle.
Bir kez daha VM'in becerikliliği önem kazanmaktadır. DOS kullanıcıları VM'i
çalıĢtıran daha güçlü bir iĢlemciye gidebilirler, sonra kullanıcı DOS'un VM altında,
doğrudan VM tarafından önemli özelliği kullanarak çalıĢtırabilir. Bunlar VM tarafından
daha iyi etkileĢim yetenekleri ve DOS iĢlerini hızlandıran güçlü iĢlemcilerdir. Bir ilave
yarar da, kullanıcının DOS'un çoklu kopyalarını VM altında aynı anda
çalıĢtırabilmesidir. Böylece DOS'un tatbikatında bulunan bir takım sınırlamalar,
sınırlanmıĢ partisyon sayısı gibi, ortadan kaldırılır.
CMS'in çok güçlü bir etkileĢimli sistem olması özellikle tasarlanmıĢtır. Onun
tasarımcıları, IBM'in büyük öncelikli deste iĢlem iĢletim sistemlerinin altında çalıĢan
standart derleyiciler ve assembler'i desteklemeye karar vermiĢlerdir. Böylece
programcılar CMS altında programlarını geliĢtirip test edebilirler ve sonra IBM'in DOS
veya OS deste iĢlem sistemi altında iĢletebilirler.
VM'in ilk yılları hakkındaki ilginç bir hikaya de Ģöyle geliĢmiĢtir. IBM ya VM'i
öldurmek ya da onu desteklenmiĢ bir ürün olarak bırakmak konusunda karar vermeye
çalıĢıyordu. ġirketin o zamanki baĢkanı, VM'in gerçekten öldürülmesinin gerekliliğinin
tartıĢıldığı MVS grubu tarafından önerilen bir davete gitti. Davetten sonraki bir turda,
Learson MVS geliĢtirme grubunun MVS'i VM altında çalıĢtığını farketti O anda, eğer
VM IBM için yeterliyse aynı zamanda içinde yeterlidir kanısına vardı. VM daha sonra
desteklenmiĢ bir ürün olarak bırakıldı.
VM bazı DOS kullanıcılarına ilginç bir performans geliĢtirimini önerir. Belirli
bir donanım üzerinde çalıĢan DOS'un aynı donanım üzerinde fakat VM altında çalıĢan
DOS'tan daha etkin olduğunu beklemek oldukça mantıklıdır. Fakat tersi genellikle
doğrudur. Bu nasıl olabilir? Oldukça basit bir Ģekilde olur. Çünkü VM'in görüntülü
bellek yönetimi DOS/VS'ten daha etkindir. Buda VM için ayrı bir avantajı ortaya
koymaktadır.
VM'in popülaritesi muntazam olarak artmaktadır ve böyle devam edeceğine
inanmak için her türlü sebep mevcuttur. IBM ve diğer satıcılar performans artıĢının bu
muntazam akıĢını muhafaza etmiĢlerdir. Görüntü makineli iĢletim sistemleri fikrinin
değerli Ģey olduğunu ispatlamıĢtır.VM, CP/M ve UNIX sistemleri gibi, nadir bir fikirde
fayda gören tasarımcılar tarafından küçük bir dükkanda ortaya çıkarılmıĢtır. Herhangi
185
bir sistemin tasarımcılarının, ssistemlerinin gerçekleĢtirebileceği büyük baĢarıyı önceden
tahmin edebilecekleri belli değildir.
35. ÖZET
Görüntüsel makina, gerçek bir makinanın bir illüsyonudur. Bir VM iĢletim
sistemi tarafından yaratılır. Konvansiyonel (klasik) çoklu programlama sistemleri,
gerçek makinanın kaynaklarını değiĢik iĢlemler arasında paylaĢtırır.
VM'in ana bileĢenleri Control Program(CP), Conversational Monitor System
(CMS), Remote Spooling Communications Subsystem(RSCS), Interactive Problem
Control System(IPCS) ve CMS Batch Facility.
CP görüntüsel makinaların iĢletildiği bir çevre yaratır. CMS tek kullanıcılı,
etkileĢimli bir sistemdir. RSCS, VM'e bir tele-iĢlem bilgisayar-ağında kütükleri
gönderme ve alma kabiliyetini kazandırır. IPCS on-line analizi için ve VM yazılım
sorunlarını belirlemek için kullanılır. CMS Batch Facility terminal kullanıcıya, kullanıcı
bir etkileĢimli CMS makinasıyla çalıĢmaya devam ederken uzun iĢleri toplu iĢlem için
suması imkanını verir.
CP, her kullanıcının tüm makinaya komple eriĢimini veren bir ayrı hesaplama
çevresi sağlar; CMS, CP tarafından yaratılan bir tek kullanıcılı, etkileĢimli makinada
çalıĢır.
CP, gerçek makinada gerçek makinanın supervisor durumunda çalıĢır. CP
tarafından düzenlenen görüntüsel makinalar, gerçek makinanın problem durumunda
çalıĢır. CP, her görüntüsel makinanın görüntüsel supervisor durumda mı yoksa
görüntüsel problem durumda mı olduğunu da izler.
Program kesilmeleri, görüntüsel bir makinanın iĢletimi ile CP arasındaki
arayüzün bir anahtarıdır. Bir program kesilmesi oluĢtuğunda, CP kontrolü ele alır. Eğer
görüntüsel makina, görüntüsel supervisor durumda ise, CP öncelikli komutun iĢletimini
simule eder.
CP, dinamik adres tercümesini ve istenebilir sayfalı yönetimi uygulamak için
donanımlandırılmıĢ bilgisayar sistemlerinde çalıĢır. CP, gerçek belleğini, sürekli gerçek
bellek içinde kalan küçük bir çekirdek haricinde, sayfalara böler. CP tarafından
yaratılmıĢ makina, OS/MVT gibi gerçek bellekli iĢletim sistemini çalıĢtırdığında, CP,
gerçek bellek iĢletim sistemi tarafından yönetilen gerçek belleği sayfalara böler. Bir
görüntü bellekli iĢletim sistemi, CP tarafından yaratılmıĢ görüntüsel makinada
çalıĢtırıldığında, sayfalama iki düzeyde oluĢur ve bu da performans problemlerine yol
açabilir.
CP altında çalıĢan DASD cihazları minidisklere bölünebilir. Bunlar, komple
disklerin alt gruplarıdır. CP minidisklerin gerçek disklere haritalanmasını gerçekleĢtirir,
186
fakat minidiskler arasındaki boĢluklar, minidisklerin atandığı görüntüsel makinanın
iĢletim sistemi tarafından yönetilir.
VM'de terminaldeki kullanıcılar kendi görüntüsel makinalarını, sanki komple bir
fiziksel konsolları varmıĢ gibi kontrol eder.
CP, değiĢik kullanıcı öncelik Ģeması tutar.Kullanıcılar kendilerine bu öncelik
sınıflarına göre atanmıĢ olan komutları kullanabilirler.
VM'e ulaĢım, VM direktorisindeki bilgiler tarafından kontrol edilir. Bu
direktorü, VM sisteminde çalıĢma hakkı olan tüm potansiyel görüntü makinalarına ait
tanımları içerir.
CMS tek kullanıcılı, disk tabanlı iĢletim sistemidir. Kullanıcıya gerçek makinaya
atanmıĢ bulunan kaynaklara komple ulaĢım sağlar, ve güçlü program geliĢtirme
olanaklarını sağlar.
RSCS, kominikasyon ağı içindeki bilgisayarlar ve uzak iĢ birimleri arasındaki
kütük transferini sağlar.
VM, bir makinanın birçok görüntüsel bilgisayar olarak görünmesini sağlar ve
bunları herbiri değiĢik iĢletim sistemlerini destekleyebilir. Yeni bir iĢletim sistemi, VM
altında test edilebilir. Aynı iĢletim sisteminin birçok kopyası VM altında çalıĢabilir.
VM ortamında performans, hayati bir önem taĢır, özellikle de çoklu sayfalama
duzenleri tarafından mikrokodlu donanım yardımcıları, kesintilere, yazılım similasyonu
yerine doğrudan donanım emulasyonu yaparak VM sistemlerinin hızını artırır. VM, CP
çalıĢırken sistem performansını görüntüleyen kendinden bir özelliğe sahiptir.
VM, güvenlik, olurluk ve servis iĢlemleri için önemli olan birçok özelliğe de
sahiptir. Her görüntüsel makinanın adreslemesi özenle koĢullandırılır. Sisteme ve
paylaĢılan disk kütüklerine ulaĢımda password'ler istenir. Disk kütükleri sadece
okunabilir Ģeklinde olabilir. Anormal sonuçlanmalar oluĢtukları görüntüsel makinaya
iletilir. Yeni iĢletim sistemlerinin test edilmesi ve hatalardan arındırılması üretim
sürerken gerçekleĢtirilebilir. Güçlü hatalardan arındırma kabiliyetleri sağlanmıĢtır.
Servis belirteçleri üretim iĢlemi diğerlerinde devam ederken diagnostik programları bir
görüntüsel makinada çalıĢtırabilir.
Öyle görünüyor ki, VM'in popülerliği bundan sonra daha da artacaktır. VM,
MVS'den daha kapsamlı ve yeterli etkileĢimli iĢlem olanakları sağlamaktadır. DOS
kullanıcısına, VM'in etkileĢimli becerilerinden yararlanırken aynı anda artan
kabileyetlerden de yararlanması için yol açar. MVS, VM altında çalıĢabildiği için, MVS
kullanıcıları daha güçsüz ve etkisiz TSO yerine, VM yoluyla etkileĢimli yetenekler
katabilirler.
187
BÖLÜM 9
UNIX ĠġLETĠIM SĠSTEMĠ
36.Unix ĠĢletim Sistemi
Her ne kadar iĢletim sistemi kavramları sadece kuramsal terimlerle ele alınsalar
da, bunları uygulamada görmek yararlı olacaktır. Bu bölüm UNIX'in bir versiyonu olan
4.2BSD iĢletim sisteminin detaylı bir açıklamasını sunmaktadır. Ġlk önce UNIX'in kısa
bir tarihçesi, kullanıcı ve programcı arayüzlerinin gösterimi üzerinde duracağız. Daha
sonra UNIX'in kullanıcı arayüzünü desteklemek için kullandığı yapıları ve algoritmaları
sunacağız.
36.1. Tarihçe
Unix'in ilk versiyonu 1969 yılında BELL laboratuarlarındaki araĢtırma grubunda
çalıĢan KEN THOMPSON tarafından geliĢtirildi. Çok geçmeden gruba DENNIS
RITCHIE adlı bir kiĢide katıldı. Thompson, Ritchie ve araĢtırma grubundaki diğer
kiĢiler Unix'in ilk versiyonunu ürettiler.
Ritchie önceleri Multics projesinde çalıĢmıĢtı. Multics yeni iĢletim sistemi
üzerinde etkiliydi, hatta Unix ismi Multics'den gelmiĢtir. Kütük sisteminin temel
organizasyonu, komut yorumlayıcısının temel düĢüncesi, her komut için ayrı bir
iĢleminin kulanılması, temel satır editleme karakterleri (# son karakteri silmek için, @
tüm satırı silmek için ) ve diğer birçok özelikler direkt olarak Multics'den geldi. Bunun
yanında çeĢitli iĢletim sistemlerinin, MIT CTSS & XDS-940 özellikleride kullanıldı.
Ritchie ve Thompson Unix üzerinde uzun süre çalıĢtılar. Unix'in ilk versiyonu
üzerindeki çalıĢmalarının sonucunda ikinci versiyonu, PDP-11/20, üretildi. Üçüncü
versiyonu, evvelce kullanılan assembly dili yerine büyük bir kısmı C ile yazılmıĢtı. C
dili Bell laboratuarlarında Unix'i desteklemek için geliĢtirildi. Unix 11/45 ve 11/70 gibi
PDP-11'in üst modellerine de uyarlandı. Unix, C dilinde yazıldığında sisteme multiprogramming ve diğer geliĢmeler eklendi ve 11/45 gibi sistemlere multiprogramming
için donanım desteğiyle birlikte uyarlandı.
Unix iĢletim sistemi geliĢtikçe daha çok kullanılır oldu ve zamanla bir kaç
üniversitede kullanılmaya baĢlandı. Unix'in 6. versiyonu Bell laboratuarları dıĢında
piyasada kullanılan ilk versiyonudur ve 1979 yılında piyasaya çıkarılmıĢtır. Ġlk Unix
sistemlerinin versiyon numarası dağıtım yapıldığında o an piyasada bulunan UNIX
PROGRAMMER MANUAL kitabının basım numarasına karĢılık gelir.
188
1978 yılında 7. versiyonu piyasaya sürüldü. Bu Unix sistemi PDP-11/70 ve
INTERDATA 8/32 üzerinde çalıĢtırıldı. Bu sistem modern Unix sistemlerinin atası
sayılmaktadır. VAX'larda kullanılan versiyonu 32V olarak bilinmektedir.
7.versiyonun piyasaya sürülmesinden sonra Unix destekleme grubu (UNIX
SUPPORT GROUP USG) idari kontrolu ve sorumluluğu araĢtırma grubundan aldı. Bu
ilk organizasyonun temeliydi. Unix, artık sadece bir araĢtırma aracı değil bir ürün
oluyordu. Ama, araĢtırma grubu, kendi deneylerini desteklemek için Unix versiyonunu
geliĢtirmeye devam ettiler. 1985'de araĢtırma grubu tarafından geliĢtirilmekte olan
Unix'in 8. versIyonuydu ve sadece Bell Laboratuarlarında kullanılıyordu.
Unix Destekleme Grubu temel olarak AT&T içinde Unix için destek sağladı.
AraĢtırma grubunun piyasaya ilk sürdüğü SISTEM III idi ve 1982 yılında çıkarıldı.
SISTEM III 7. versiyonun, 32V(VAX'larda kullanılan versiyonu) ve araĢtırma grubu
dıĢında baĢka grupların geliĢtirdikleri bir kaç Unix sisteminin özelliklerini bir araya
toplamıĢtır. UNIX/RT'nın (a real-time UNIX system) özellıkleri PWB' nin çeĢitli
kısımları ile birlikte System III'de bulunmaktadır.
Unix destekleme grubu (USG) 1983'de SYSTEM V'i piyasaya sürdü. Bu
ekseriyetle SYSTEM III''den çıkarılmıĢtı. ÇeĢitli Bell iĢletim Ģirketlerinin AT&T'den
ayrılması, AT&T' nin SYSTEM V'i pazarlamasına neden oldu. USG(Unix Destekleme
Grubu) USDL (Unix System Development Laboratory) olarak yeniden oluĢturuldu ve
USDL' nin 1984 'de piyasaya çıkardığı ürün Unix system V'in ikinci uyarlamasıdır.
Unix'in küçük hacmi ve açık tasarımı, RAND, BBN, Illinois Üniversitesi,
Harvard hatta DEC gibi bir çok Bilgisayar Bilimleri Organizasyonlarında Unix tabanlı
bir çalıĢmanın kullanılmasını sağladı. Bell laboratuarları ve AT&T dıĢındaki en etkili
Unix geliĢtirme grubu California'daki BERKELEY Üniversitesi olmuĢtur.
Ġlk Berkeley VAX UNIX çalıĢması 1978 yılında BILL JOY ve ÖZALP
BABAOĞLU tarafından virtual memory, demand paging ve page replacement'in
özellikleri 32V'ye ilave edilmesi ile 3BSD elde edildi. 3BSD'nin çok büyük belleği
Berkeley'in kendi Franz Lisp'i gibi büyük programların geliĢtirilmesine izin verdi.
Bellek yönetimi DARPA(Defense Advanced Research Projects Agency )'yi bu projeyi
parasal olarak desteklemeye ikna etti.
DARPA için yapılan 4BSD çalıĢması Unix ve Networking topluluklarından
birçok seçkin kiĢinin bulunduğu bir yönetim komitesi tarafından idare ediliyordu. Bu
projenin hedeflerinden birisi DARPA Internet Networking protokolları için destek
sağlamaktı. Bu destek her konuda sağlandı. 4.2BSD'de yerel bölge ağları ve geniĢ bölge
ağları dahil birçok değiĢik network olanakları arasında rahatlıkla iletiĢim kurmak
mümkündür.
Bunlara ilave olarak Unix'in tasarım ve uygulanmasını geliĢtirmek amacı ile
Berkeley iĢletim sistemlerinin birçok özelliklerini adapte etti. TENEX iĢletim sisteminin
terminal satır editleme fonksiyonlarının çoğu yeni bir terminal sürücüsü tarafından
sağlandı. Yeni bir kullanıcı arayüzü (C_SHELL), yeni bir text editörü (EX/VI), Pascal
189
ve Lisp derleyicileri ve bir çok yeni sistem programı Berkeley'de yazıldı. 4.2BSD için,
VMS iĢletim sistemine kıyasla bazı etkinlik ilerlemeleri elde edildi.
Berkeley'de
yapılan
Unix
yazılımları
BERKELEY
SOFTWARE
DISTRUBUTION adıyla dağıtıldı. 3BSD'yi takip eden Berkeley Vax Unix sistemlerine
(her nekadar 4.1BSD ve 4.2BSD gibi özel uyarlamalar olduysa da) 4BSD olarak
baĢvurmak daha elveriĢlidir. 2BSD ve 4BSD sembolik isimleri Berkeley Unix'in PDP11 ve VAX dağıtımları için kullanılır. Ilk olarak 1983'de dağıtılan 4.2BSD Berkeley
DARPA Unix projesinin asıl ürünü olmakla beraber o sırada çalıĢmalar devam
etmekteydi. 2.9BSD PDP-11 sistemleri için eĢdeğer bir uyarlamadır.
4BSD ilk piyasaya sürüldüğü tarih olan 1979'dan sistem III'ün piyasaya
sürüldüğü 1982'ye kadar VAX makinaları için seçimlik iĢletim sistemiydi. 4BSD halen
birçok araĢtırma ve networking kuruluĢları için en iyi seçimdir.
Bununla birlikte hali hazırdaki Unix sistemleri seti 8.versiyonla, system V(ikinci
düzenlemesi) ve 4.2BSD ile sınırlı değildir. Unix iĢletim sistemi popüler oldukça bir
çok değiĢik bigisayara ve bilgisayar sistemlerine uyarlandı. Çok çeĢitli Unix ve Unix'e
benzer iĢletim sistemleri yaratıldı. DEC Vax'lar için ULTRIX isimli kendi ürünü olan
Unix'i destekler. Microsoft, Unix'i XENIX adıyla Intel 8088 iĢlemcisi için tekrar
yazıldı. IBM'in kendi PC ve mainframelerinde Unix bulunmaktadır. Unix, iĢletim
sistemi teoriğinin ve pratiğinin önemli bir kısmı oluĢmuĢur. Unix akademik çalıĢmalar
için mükemmel bir araçtır. Örneğin, hem TUNIS iĢletim sistemi [Holt 1983] ve XINU
iĢletim sistemi [Comer 1984] Unix kavramlarına dayandırılmıĢtır. Ama bu sistemler
sınıf çalıĢmaları için geliĢtirilmiĢtir. Ritchie ve Thompson 1983'de Unix üzerindeki
çalıĢmalarından dolayı ACM Turing ödülü ile ödüllendirildiler.
Bu bölümde kullanılan özel Unix versiyonu, 4.2BSD'nin VAX versiyonudur.
Bu sistem demand paging ve networking gibi bir hayli ilginç iĢletim sistemi
kavramlarını yerine getirdiği için kullanılır. Vax uygulamaları kullanılır, çünkü 4.2BSD
Vax'lar için geliĢtirilmiĢtir. Bu makina hala uygun kaynak noktasını Motorola 68000
veya National 32032 gibi diğer donanımlardaki uygulamalarına rağmen gösterir.
36.2. Tasarım Ġlkeleri
Unix, time-sharing ilkesi ile çalıĢan bir sistemdir. Standart kullanıcı arayüzü
basit ve istenirse baĢkasıyla değiĢtirilebilir. Kütük sistemi çok seviyelidir ve ağaç yapısı
direktorilerden oluĢtuğundan, kullanıcıların kendi alt direktorilerini yaratmalarına
olanak tanır. Tüm kullanıcı veri kütükleri basit olarak bir byte sırasından oluĢmuĢtur.
Disk kütükleri ve I/O aletleri mümkün olduğunca birbirlerine benzer
düĢünülmüĢlerdir. Böylece makina bağımlılıkları ve özellikleri mümkün olduğunca
çekirdek içerisinde toplanır, hatta çekirdek içindekilerin çoğu bile aygıt sürücülerine
adanmıĢ durumdadır. Unix, multiple-process(çoklu iĢlem)'leri destekler. Bir proses
kolaylıkla yeni prosesler yaratabilir. CPU scheduling basit bir öncelik algoritmasıdır.
Bellek yönetiminde yerdeğiĢtirmeli değiĢken saha algoritması kullanılır(a variable
190
region MVT algorithm with swapping). 4.2BSD bellek yönetimi ve CPU programlaması
kararlarını desteklemek için demand paging'i bir mekanizma gibi kullanır.
Unix, kiĢisel bilgisayarlar için mükemmel bir iĢletim sistemi örneğidir. Unix
ilk olarak bir programcı olan Ken THOMPSON tarafından düĢünüldü ve daha sonra
aralarına katılan Dennis RITCHIE ile kendi kullanımları için bir sistem olarak
geliĢtirildi. Algoritmaların çoğu çoğu hızlı veya herĢeye cevap verecek Ģekilde değil
sadece basit olarak tasarlandı. Unix'in basit ve anlaĢılır tasarımı birçok taklit ve
değiĢikliğe neden olmaktadır.
Her ne kadar Unix'i tasarlayanların diğer iĢletim sistemleri hakkında yeterli
bilgileri vardı ise de, iĢletime girmeden önce ince ayrıntılarına kadar açıklanmıĢ değildi.
Bu esneklik, sistemin geliĢimde anahtar faktörlerinden biri olarak gözükür. Bazı tasarım
ilkelerinin kullanılmasına rağmen bunlar baĢlangıçta belirtilmemiĢti. Unix programcılar
tarafından programcılar için tasarlandı. Bu yüzden devamlı interaktifdir ve program
geliĢtirme olanakları daima yüksek öncelikli olmuĢtur.
ĠĢletim sistemi ekseriyetle, bir sistem programlama dili olan C'de yazılmıĢtır. C
dili ne Thompson ne de Ritchie assembly dilinde uğraĢmak istemediklerinden dolayı
Unix'i desteklemek için geliĢtirilmiĢtir. Unix'in çalıĢacağı makina veya makinalardaki
belirsizlik yüzünden assembly dilinin kullanımasından kaçınılmalıydı. Bu Unix'in bir
donanım sisteminden diğerine adapte olma problemini azalttı.
BaĢlangıçtan itibaren, Unix geliĢtirme sistemleri Unix kaynaklarının tamamına
ON-LINE olarak sahiptir ve sistemi geliĢtirenler geliĢtirilmekte olan sistemleri esas
sistem olarak kullanmıĢlardır. Bu özellik, aksaklıkların tespit edilmesi ve
düzeltilmesinin yanı sıra yeni olanaklar ve yeni uygulamaların tespit edilmesini
kolaylaĢtırmıĢtır. Unix'in bugün mevcut olan birçok türünü teĢvik etmiĢ, fakat bunun
faydaları zararlarından çok olmuĢtur. Bir Ģey bozulduğunda sistemin bir sonraki
uyarlamasını beklemeye gerek kalmadan bulunduğu yerde tamir edilebilir. Böylesi
düzeltmeler, yeni olanaklar ile birlikte sonraki uyarlamalara dahil edilebilir.
PDP-11 ve daha önceki bilgisayarların büyüklüğünden kaynaklanan problemler
daha etkin bir sistem yapılmasına yol açtı. Diğer sistemler patolojik Ģartlarla uğraĢmak
için daha hassas algoritmalara sahip iken, Unix bu tür Ģartları tedavi edeceğine bunları
önlemeye çalıĢır. Diğer sistemler, makro uzantıları ve kaba kuvvet kullanılırken, Unix
çoğunlukla daha kurnaz veya en azından daha basit yaklaĢımlar geliĢtirmek zorundaydı.
36.3. Programcı Arayüzü
Tüm bilgisayar sistemlerinde olduğu gibi, Unix' de iki parçadan oluĢur.
Çekirdek kısmı ve sistem programları. Unix iĢletim sistemini aĢağıdaki gibi tabakalar
halinde gösterebiliriz. Burada sistem çağrı arayüzü ile fiziksel donanım arasında kalan
kısım bize çekirdek kısmı gösterir. Kütük sistemi, CPU scheduling (MIB planlama),
bellek yönetimi, ve diğer iĢletim sistemleri fonksiyonları sistem çağrıları ile
ÇEKIRDEK tarafından gerçekleĢtirilir. Sistem programları ise derleme ve kütük
uygulamaları gibi fonksiyonların iĢletilmesıne olanak verir. Unix'de programcı arayüzü
191
ile sistem çağrıları, kullanıcı ara yüzü ile sıklıkla kullanılan sistem programları ifade
edilmektedir.
Unix'de sistem programlarının çoğu C dili ile yazılmıĢtır ve Unix Programmer's
Manual (Unix programcı el kitabı) bütün sistem komutlarını C fonksiyonları olarak
belirtmektedir. VAX sisteminde 4.2BSD için C ile yazılmıĢ bir sistem programını
baĢka bir 4.2BSD sisteminde kullanmak genellikle mümkündür. Bu arada sistem
komutlarında görülecek bazı küçük aksaklıklar derleyicilerden kaynaklanır.
Sistem çağrıları Unix'de genellikle 3 kategoride gruplanabilir:
1) Kütük iĢleme,
2) IĢlem (process) kontrol,
3) Bilgi iĢleme.
Kullanıcı
Shell ve Komutlar
Derleyiciler ve Yorumcular
Sistem Kütüphaneleri
Çekirdek için Sistem Çağrı Arayüzü
Sinyaller
Kütük Sis.
CPU planlama
Uç Kontrol
Değiştirmeler
Sayfa Değiştirme
Karakter g/ç sis.
Blok g/ç Sis.
Demand Paging
Uç sürücüler
Görüntü Bellek
Donanım için Çekirdek Sistem Arayüzü
Uç Kontrolcular
Aygıt Kontrolcular
Bellek Kontrolcular
Uçlar
Disk ve tapeler
Fiziksel Bellek
Şekil- 93. 4.2.BSD Katman Yapısı
36.3.1. File ĠĢleme
Unix'de kütük, byte'ların bir düzen içinde sıralanmasıdır veya baĢka bir deyiĢle
kullanıcıların bilgileri bir isim altında saklamalarına olanak veren bir ortamdır.
Normalde değiĢik programlar için değiĢik seviyelerde yapı beklenir. Fakat çekirdek
sistemin kütükler üzerinde herhangi bir etkiye sahip olmaması böyle bir durumu
ortadan kaldırır. Örneğin, Unix'de metin kütüğü birbirinden yeni satır karakteri adlı bir
karakterle ayrılmıĢ ASCII karakterlerden oluĢan satırların bir araya gelmesi ile oluĢur.
Unix'de kütükler ağaç Ģeklinde yapılaĢmıĢ directory'ler Ģeklinde organize edilir.
Aslında directory'lerde birer kütüktürler ve diğer kütükleri nasıl bulabileceğimizi
tutarlar. PATHNAME directory'deki path'ler vasıtasıyla bir kütüğe ulaĢmayı sağlayan
karakter dizinlerdir. Söz dizimi yönünden bir pathname "/" karakterleri ile ayrılmıĢ
kütük ve directory isimlerinden oluĢur. Örneğin, /user/local/font pathname'inde ki ilk
192
slash (/) directory ağacının kök elemanını oluĢturur ve root (kök) adıyla anılır. Bir
sonraki eleman (usr) ise kök directory'nin bir alt directory'sidir. Aynı Ģekilde local'de
usr'in bir alt directory'sidir. Son isim font burada bir kütük ismi veya local'in bir alt
directory'sidir. font bir directory'mi, yoksa bir kütük mü olduğu pathname sözdimi ile
anlaĢılamaz.
Unix'de iki türlü pathname mevcuttur.
1) Absolute(kesin) pathname
2) Relative(göreceli) pathname
Absolute pathname kök directory'den baĢlar ve baĢtaki bir '/' ile ayırt edilebilir.
/user/local/font bir absolute pathname'dir. Relative pathname ise aktif directory'de
baĢlar. Örneğin, local/font aktif directory olan local directory'si içindeki bir font
directory'sini veya bir kütüğü belirtir. Burada local/user'nin içinde olabilir veya
olmayabilir.
Bir kütük, bir veya daha fazla directory içinde birden fazla isimle bulunabilir.
Bu tür çoklu isimlere LINK denir. 4.2BSD baĢka bir kütüğün absolute pathname' ini
içeren kütüklere SEMBOLIK LINKLER denir. Sembolik linkler directory' leri belirtirler
ve kütük sistemi doğrultusunda çalıĢırlar.
Diğer bir link türü ise HARD LINKLER' dir. Örneğin, "." bir hard(fiziksel)
linktir ve kütüğün kendisini belirtir. ".." adlı kütük ise aktif directory'nin bir üst
seviyedeki(parent) directoryle bağlantı kurar. Buna bir örnek verirsek, aktif
directory'miz /user/jlp/programs ise, ../bin/wdf bize /user/jlp/bin/wdf directory'sine
ulaĢmamızı sağlar.
Unix'in fiziksel aygıtlarının da kütük sisteminde birer adı vardır. Bunlar
DEVICE SPECIAL FILES (aygıtlara özel kütükler) veya SPECIAL FILES(özel
kütükler)'dirler ve aygıt arayüzü vasıtasıyla çekirdek sisteme bildirilirler. Ancak
kullanıcılar tarafından normal sistem çağrıları ile diğer kütükler gibi ulaĢılabilirler.
Tipik bir Unix kütük sistemini Ģematik olarak göstermek mümkündür.
Normalde kök directory (/) nispeten daha alt directory'lere sahiptir. Bunlardan /vmunix
iĢletim sisteminin ikili boot imajını; /dev aygıt özel kütüklerini, örneğin /dev/console,
/dev/lp0, /dev/mt0 vb. içerir. /bin gerekli Unix sistem programlarının ikili hallerini
tutar. Diger ikili programlarda /user/bin (uygulama sistem programları, örneğin metin
formatçısı), /user/ucb (AT&T tarafından yazılmıĢ sistem programları) veya
/user/local/bin içinde olabilirler. Kütüphane kütükleri, örneğin C, Pascal, ve Fortran
kütüphane altprogramları /lib (veya /user/lib veya /user/local/lib) içinde bulunur.
Kullanıcıların kütükleri genellikle /user directory'si içinde ve her kullanıcı için
ayrı bir directory'de saklanır. Örneğin CAROL için bir kullanıcı directory'si normal
olarak /user/carol içinde olacaktır. Büyük sistemlerde bütün directory'ler daha kolay
193
yönetilmesi açısından gruplandırılırlar. Örneğin, /user/prof/avi ve /user/staff/carol
Ģeklinde kullanıcı personele göre gruplama yapılabilir. Idare ile ilgili kütük ve
programlar, örneğin, password kütüğü, /etc'nin içindedir. Geçici olarak kullanılan
kütükler /tmp veya /user/tmp içindedir ve normalde hergün silinirler.
vmunix
spell
DEV
consol
lp0
...
BIN
BIN
sh
csh
...
UCB
libc.a
LOCAL
LIB
...
/
USR
USER
JLP
AVI
LIB
passwd
group
TMP
init
...
TMP
Şekil 94. Tipik UNIX Directory Yapısı
194
telnet
man
...
BIN
LIB
...
INCLUDE
...
ETC
troff
...
TMAC
TROFF
...
Burada gösterilen directory'ler daha fazla yapıya sahip olabilirler. Örneğin
CAROL' un bir projesini tutan bir pogram /user/staff/carol/project içinde tutulabilir.
Bu birbiriyle ilgili kütüklerin ve directorylerin bir arada toplanması kullanıcılar ve
onların programları tarafından oluĢturulur. IĢletim sisteminde çekirdek sistem yalnızca
/etc/init'in varlığı ile ilgilenir.
Temel kütük iĢlemleri için gerekli sistem çağrıları ise creat, open, read, write,
close, unlink'dir.
creat sistem çağrısı verilen pathname içinde bir boĢ kütük yaratır. open ile kütük
açılır ve bu sistem çağrısı bir pathname, bir mode(read, write, read/write) içerir. File
descriptor(kütük tarifleyici) adlı bir küçük tamsayı meydana getirir. Kütük tarifleyici bu
iĢlem(process) için açık bulunan kütüklerin tablosunda bir index iĢlemi görür.
Tarifleyici, sıfırdan baĢlar ve nadiren altı veya yediye kadar çıkar. Bu rakam aynı anda
açık kütüklerin sayısına bağlıdır. Daha sonra read veya write sistem çağrısına geçilir.
Bu komutlarla kütüğe bilgi giriĢi veya kütükten bilgi çıkıĢı yapılır. close sistem
çağrısıyla da kütükler kapatılır.
Kütük hakında ki bilgiler, ki bunlar kütük boyutu, korunma modu, sahibi, vb.
stat sistem çağrısı ile elde edilebilir. Bu bilgilerin değiĢtirilmesini sağlayan üç sistem
çağrısı bulunmaktadır.
1) rename, kütük isminin değiĢmesini,
2) chmod, korunma modunun değiĢtirilmesi
3) chown, sahibinin değiĢtirilmesini sağlar.
Directory'ler mkdir komutuyla oluĢturulur, rmdir komutu ile de directory silinir
ve chdir komutuyla da directory değiĢtirilir.
36.3.2. ĠĢlem Kontrol
ĠĢlem(process), bir programın iĢletimde olmasıdır. ĠĢlemler bir iĢlem belirteci
(process identifier) tarafından belirlenirler. Bu belirteç bir tam sayıdır. Yeni bir iĢlem
fork sistem çağrısıyla üretilir. fork sistem çağrısı orijinal adres alanının kopyası olan ve
hemen hemen birbirinin aynısı olan iki iĢlem yaratır. Bu iki iĢlem (ebeveyn ve çocuk)
fork komutundan sonra tek bir farkla komut iĢlemeye devam ederler. Bu fark yeni
iĢlemde(çocuk) fork için dönüĢ kodu sıfırken, bu iĢlem için sıfırdan farklı olan iĢlem
belirteci ebeveyne dönüĢ kodu olarak gelir.
Genel olarak execve sistem çağrısı bu iki iĢlemden biri tarafından görüntü
bellek alanını yeni bir program ile değiĢtirmek için fork komutundan sonra kullanılır.
execve sistem çağrısı belleğe bir ikili kütük yükler ve onun iĢletimine baĢlar. Bir
iĢlem exit sistem çağrısı kullanılarak bitirilebilir ve wait komutu kullanılarak ebeveyn
iĢlem bekletilebilir. wait sistem çağrısı iĢletimi durdurulmuĢ olan çocuk iĢlem için iĢlem
kimliklerini verir. Bu iĢlem çağrı komutlarını daha düzgün açıklamak istersek fork ve
wait bir altprogramın çağrı(call) ve geri dönüĢ(return) komutlarına, execve ise daha
ziyade goto deyimine denk gelir.
195
ĠĢlemler arasında iletiĢim kurmanın en basit yolu PIPE'lardır. Pipe'lar(borular)
fork'dan önce oluĢturulur ve fork ile execve arasında bitiĢ noktası bulunur. Bu borular
aslında 2 iĢlem(process) arasında bir byte'lar kuyruğudur. Bu borulara normal bir kütük
gibi bir kütük tanımlayıcı(file descriptor) ile ulaĢılır. Bir iĢlem bu boruya atama
yapabilir, diğer iĢlem ise bunu okur. Bu pipe'ların hacmi(genelde 4096 byte) sistem
tarafından sabitleĢtirilir. BoĢ bir borudan okuma yapmaya veya dolu bir boruya atama
yapmaya kalkıldığında borunun statüsü değiĢene kadar iĢlemin bloklanmasına sebep
olur.
Bütün bu kullanıcı iĢlemleri bir orijinal iĢlemin torunlarıdır. Bu iĢlem INIT'tir ve
1 numaralı iĢlem belirtecine sahiptir. Birbiriyle etkileĢimli(interactive) çalıĢma imkanı
olan herbir uç(terminal) portu bir getty prosesine sahiptir. Getty, uç parametrelerinin ilk
değerlerini hazırlar ve kullanıcıyı LOGIN NAME (açıĢ ismi) için bekler. Bu isim bir
execve vasıtasıyla bir argümant olarak LOGIN prosese gider. LOGIN kullanıcının
Ģifresini(password) alır, ve onu /etc/passwd kütüğündeki Ģifre ile karĢılaĢtırır. Eğer
doğruysa kullanıcıya hizmet verilmeye baĢlanır. LOGIN iĢleminin kullanıcı
belirtecini(user identifier) ayarladıktan sonra sonra bir SHELL'i veya bir KOMUT
YORUMCUSU (Command Interpreter)'nu iĢletir(SHELL ve KULLANICI BELIRTECI
/etc/passwd içindedir ve kullanıcın açıĢ ismi (login name) tarafından ulaĢılır). SHELL
kullanıcın normal olarak iletiĢim kurduğu açılıĢ bölümünün geri kalan kısmıdır ve shell
kendi içinde komutlar için altprogramlara ayrılır.
Kullanıcı belirteçleri, kullanıcıların hangi sistem çağrılarını ki bunlar özellikle
kütük ulaĢımları ile ilgilidirler, kullanma yetkisine sahip olduklarını belirlemek
amacıyla çekirdek sistem
tarafından kullaılırlar. Bunun yanısıra birde GRUP
BELIRTECI(group identifier) vardır ki belli durumlardaki kullanıcılara benzer
imtiyazlar sağlamak amacıyla kullanılır. LOGIN prosesi kullanıcıya izin verilen bütün
grupların içine SHELL'i yerleĢtirir ve bu iĢ /etc/passwd ve /etc/group kütükleri
tarafından oluĢturulur.
Çekirdek sistem tarafından kullanılan 2 kullanıcı belirteci (user identifier) vardır.
EFFECTIVE USER IDENTIFIER (etkin kullanıcı belirteci) kütük ulaĢım izinlerini
belirlemek amacıyla kullanılan bir belirteçdir. Eğer bir execve tarafından halıhazırda
yüklü olan programın kütüğü bir setuid (setuser identification) bitine sahipse, iĢlemin
etkin kullanıcı belirteci kütüğün sahibinin kullanıcı belirtecine göre ayarlanır. Bu arada
REAL USER IDENTIFIER (gerçek kullanıcı belirteci) olduğu gibi kalır. Bu durum belli
bir takım iĢlemlerin halihazırda normal kullanıcılar tarafından iĢletilebilirken olağan
imtiyazlardan daha fazlasına sahip olabilme imkanı sağlar. Aynı Ģekilde birde gruplar
için setgid (set group identification) biti de vardır.
36.3.3. Sinyaller
Sinyaller, yazılım kesintilerine benzer istisnai Ģartları kullanan kolaylıklardır.
19 farklı sinyal vardır ve herbiri belli bir Ģarta karĢılık gelir. Bir sinyal bir klavye
kesintisi, iĢlemdeki kötü bellek referansı gibi bir hata ya da shell'den iĢ kontrol sinyal
veya zamanlayıcı gibi bir takım asenkron olaylar sonucu yaratılabilir.
196
Kesinti sinyali, sigint bir komutu tamamlamadan önce durdurmak için
kullanılabilir. Genellikle ^C karekteri(ASCII 3) ya da daha genel olarak, DELETE
karekteri (ASCII 127) tarafından üretilir. 4.2BSD'lerde önemli klavye karekterleri her
terminal için bir tablo tarafından tamımlanır ve kolaylıkla yeniden tanımlanabilir.
quit sinyali, sigout, genellikle ^I karakteri (ASCII 28) tarafından üretilir. Quit sinyali
hem iĢletilmekte olan programı keser hem de aktif directory'yi core diye adlandırılan bir
kütük için aktif bellek imajını baĢlatır. Core kütüğü debugger'ler tarafından kullanılır.
sigill geçersiz bir komut tarafından ve sigselv bir iĢlemin geçerli görüntü bellek
sahasının dıĢındaki sahayı adresleme isteği tarafından üretilir.
Ayarlamalar ihmal edilen çoğu sinyaller için (etkilenmemek için) ya da kullanıcı
iĢlemi tarafından çağırılan bir rutine (bir sinyal tutucu) için yapılabilir. Hiçbir sinyal,
bir sinyal tutucu tarafından ihmal edilemez ya da kaçırılamaz (kill sinyali, 9 numaralı
sigkill). sigkill örneğin sigint ya da sigquit diğer sinyalleri ihmal eden, çalıĢmakta olan
bir iĢlemi öldürmek için kullanılabilir.
Sinyaller kaybedilebilir. Eğer gönderilen bir önceki sinyal iĢlem tarafından
kabul edilmeden aynı cins bir baĢka sinyal gönderilirse, ilk gönderilenin üzerine
yazılır ve iĢlem sadece sonuncuyu algılar.
36.3.4. Bilgi ĠĢleme
Sistem çağrıları internal timer (gettimer/settimer) ve aktif zamanın her
ikisinide set etmek ve 1 Ocak 1970'den (gettimeofday/settimeofday) itibaren birkaç
mikrosaniyede dondurmak için ortaya çıkarlar. Ek olarak iĢlem, iĢlem tanımlayıcı
(getpit), grup tanımlayıcı (getgid), iĢletimdeki makinanın adı (gethostname) için
sorular sorar.
36.3.5. Kütüphane Rutinleri
Unix sistem çağrı arayüzü, geniĢ bir kütüphane routine'i ve header dosyası seti
tarafından büyütülür ve desteklenir. Header dosyaları, sistem çağırılarında kullanılan
karmaĢık veri yapılarının açıklanmasını sağlar. Ek olarak, geniĢ bir fonksiyon
kütüphanesi ek program desteği sağlar.
Örneğin, Unix G/Ç çağrıları byte block'larının okunma ve yazılmasını sağlar.
Bazı uygulamalar aynı anda sadece bir byte okuma veya yazma yapmak isteyebilir. Aynı
anda sadece bir byte okuma veya yazma yapmak her byte için bir sistem çağırısı
isteyerek mümkündür. Bu da büyük bir overhead getirir. Bir çok standart kütüphane
routine'i yerine (stdio.h header kütüğü üzerinden eriĢilen standart g/ç paketi), yerel
tamponlar kullanarak bir kerede birkaç bin byte okuyup, yazbilen ve g/ç istenildiğinde
bu tamponlar arasında aktarma yapabilen bir baĢka arayüz sağlar. FormatlanmıĢ g/ç,
standart g/ç paketi tarafından da desteklenir.
Ġlave kütüphane desteği matematiksel fonksiyonlar, ağ (network) eriĢimi, veri
çevirimi ve bunun gibi Ģeyler de sağlanır. 4.2BSD çekirdeği, C program kütüphanesi
197
336 kütüphane fonksiyonuna sahipken, 153 sistem çağırısını destekler. Buna rağmen
kütüphane fonksiyonları gerekli oldukları sistem çağırılarıyla sonuçlanırlar (örnek
olarak getchar kütüphane routine'i eğer kütük tamponu boĢsa bir okuma sistem
çağırısıyla sonuçlanır). Programcı için genellikle temel çekirdek çağırısı setiyle
kütüphane fonksiyonları tarafından sağlanan ek fonksiyonları ayırmak gereksizdir.
36.4. Kullanıcı Arayüzü
Programcı ve kullanıcının herikiside Unix'in iĢletim için yazılmıĢ ve elde
edilebilir Ģekilde bulunan sistem programları setiyle uğraĢır. Bu programlar
foksiyonlarını desteklemek için gerekli sistem çağırılarını kendileri yaparlar. Fakat
sistem çağırılarının bir programın içinde bulunan ve kullanıcı tarafından bilinmesine
gerek yoktur.
Yaygın sistem programları birkaç kategoride sınıflandırılabilir. Çoğu kütüğe ya
da directory'ye uyarlanabilirdir. Örneğin directory'lerle uğraĢmak için, yeni bir
directory yaratan mkdir, directory'yi ortadan kaldıran rmdir, current directory'i kesin
bir baĢkasıyla değiĢtiren cd ve yürürlükteki directory'nin kesin path adını yazan pwd.
ls programı aktif directory'deki dosyaları listeler. 18 seçenekten herhangibiri
görüntülenmekte olan dosyaların özelliklerini de sorabilir. Örneğin -l seçeneği dosya
adını, dosya sahibini, korumasını, yaratılma tarih ve zamanını büyüklügünü (byte
olarak) gösteren uzun bir liste sorar. cp programı bulunan bir dosyanın bir
kopyasını yaratır. mv directory ağacındaki bir kütüğü bir yerden baĢka bir yere taĢır.
Çoğu durumda basit olarak bir dosyaya yeni bir isim vermek istenilebilir. Eğer böyle
birĢey gerekirse dosya baĢka bir yere kopyalanır ve eski kopyası silinir. Bir dosya
unlink sistem çağırısı yapan rm programı tarafından silinir.
Terminalden bir dosya görüntülemek için cat'ı çalıĢtırmalıdır. cat programı
dosyaların bir listesini alır ve onları birleĢtirir, sonucu da standart çıktıya, genellikle
terminale kopyalar. Doğal olarak yüksek hızlı CRT'lerde dosya okunurken çok
hızlandırılabilir. more programı kullanıcı bir sonraki ekranı görmek için bir karektere
basana kadar ekranı durdurur. head programı dosyanın sadace ilk birkaç satırını
görüntülerken tail son bir kaç satırını gösterir.
Bunlar Unix'de geniĢ olarak kullanılan temel sistem programlarıdır. Ek olarak
bir kaç editör (ed, sed, emacs, vi, ...), derleyici (C, Pascal, Fortran, ...), metin
düzenleyici (troff, tex, scribe, ...) vardır. Ayrıca sıralama(sort), dosya karĢılaĢtırma
(cmp,diff ), örnek arama (mail) ve birçok diğer Ģeyler için programlar vardır.
36.4.1. Shell ve Komutlar
Programların hepsi hem sistem hemde kullanıcı programları normalde komut
yorumlayıcısı tarafından iĢletilir. Unix'de komut yorumlayıcı diğerlerinde olduğu gibi
bir kulanıcı iĢlemidir. IĢletim çekirdeğinin çevresinde bulunduğu için buna SHELL
198
denir. Kullanıcılar kendi shell'lerini yazabilirler ve aynı zamanda gerçekte genel
kullanım için birçok shell vardır. Steve Bourne tarafından yazılan BOURNE SHELL
en çok kullanılandır. En azından en yaygın olarak elde edilebilir olandır. BILLY
JOY'ın ürünü olan SHELL BSD sistemlerinde en popüler olanıdır.
Yaygın olan shell'erin çoğunun komut syntax'ları benzerdir. Unix normalde iç
ilintili bir sistemdir. Shell, girilen bir prompt tarafından kabul edilen bir baĢka komutun
kabulü için olan hazır olma durumunu gösterir ve kullanıcı her satıra bir komut yazar.
Örnek olarak bu satırda %ls-l, yüzde iĢareti C shell prompt'u ve ls-l (kullanıcı
tarafından yazılan) directory listesi (uzun) komutudur. Komutlar kullanıcının aynı satıra
komut iĢleminden sonra yazacağı ve beyaz boĢlukla ayrılmıĢ (boĢluk yada tabs)
argümanlar bulundurabilir.
Buna rağmen shell'de oluĢturulan (cd gibi) birkaç komut da vardır, tipik bir
komut iĢletilebilir ikili object dosyasıdır. Birkaç directory'nin bir listesi yani SEARCH
PATH shell tarafından tutulur. Her komut için SEARCH PATH 'daki her directory
aynı isimdeki bir dosya için aranır. Dosya bulunmuĢsa yüklenir ve iĢletilir. Search path
kullanıcı tarafından set edilebilir. /bin ve /user/bin adlı directory'ler de search
path'dedir ve bir BSD sistemindeki tipik bir search path;
(./user/local/bin /user/ucb/bin /user/bin) Ģeklinde olabilir.
ls komutunun object dosyası /bin/ls'dir ve shell ise /bin/sh(bourne Shell) ya
da /bin/csh(C Shell)'dir.
Bir komutun iĢletimi bir fork sistem çagırıĢı tarıfından yapılır ve object
dosyasının execve'si tarafından izlenilir. Sonrasında
shell genellikle komut
tamamlanıncaya kadar kendi iĢletimini ertelemek için bir wait gerçekleĢtirir (Ģekil-95).
Shell'in beklememesi gerektiğini belirten basit bir syntax vardır (komut satırı
sonundaki bir [&]). Shell
sonraki background komutları denilen komutları
yorumlamaya (ya da background da çalıĢtırmaya) devam ederken bir komut
iĢletilmektedir. Shell'in wait yaptığı iĢlem foreground'da iĢletimde denilir.
4.2BSD sistemlerindeki C shell çekirdekte kısmen kurulan JOB CONTROL
denilen bir özellik sağlar. Job kontrol iĢletimin foreground&background arasında
hareket etmesine izin verir. Bunlar kulllanıcı terminalinden giriĢ istemi olan bir
background iĢi gibi çeĢitli Ģartlarda durdurulabilir ya da yeniden baĢlatılabilir. Bu,
WINDOWING (pencereleme) ya da katman arayüzleri tarafından sağlanan iĢlemlerin
çoğunun kontrolüne izin verir. Fakat fazla bir donanım gerektirmez.
36.4.2. Standart GiriĢ/ÇıkıĢ
ĠĢlemler istedikleri gibi dosya açabilirler, fakat iĢlemlerin çoğu baĢladıklarında
açık olacak(0, 1, 2 gibi) üç dosya tanımlayıcısını belirler. Bunlar standart giriĢ (0),
standart çıkıĢ (1), ve standart hata (2) olarak bilinirler. Bu dosya tanımlayıcılar iĢlemi
yöneten execve (fork'da olabilir)'dan sonra miras olarak alınır. Bu üçü sıklıkla kullanıcı
terminaline kullanıcı ne yazıyorsa okuyabilir, ve program standart çıkıĢ yazısı
199
tarafından kullanıcının ekranına çıktı yollayabilir. Standart hata dosya tanımlayıcısı
yazım için de açıktır ve hata çıktısı için kullanılır. Standart çıkıĢ sıradan çıkıĢlar için
kullanılır. Çoğu programlar standart giriĢ çıkıĢlar için dosya da kullanabilir (terminale
yapılan G/Ç den fazlasını).
Yaygın kullanılan shell'ler, bir iĢlemin standart G/Ç iĢlemi için açık olan
dosyaları değiĢtirmek için basit bir syntax'a sahiptir. Stantard bir kütüğü değiĢtirmeye
G/Ç redirection denir. Bu örnekte ls komutu aktif directory'deki dosyaların isimlerinden
oluĢan bir liste üretir. pr komutu bu listeyi bir printer için uygun sayfalar halinde
formatlar ve lpr komutu formatlanmıĢ çıktıyı /dev/lp0 gibi bir printere spool eder.
36.4.3. Pipeline'lar, Filtreler ve Shell Yazıları
Printere aktarma iĢlemi üç adımlı bir komut ile yapılabilir.
%ls ¦ pr ¦ lpr
Her düĢey bar shell'e önceki komutu çıktı için ayarlanması ve takib eden komutu
giriĢ olarak geçmesini söyler. Bir hat veriyi bir iĢlemden diğerine taĢımak için
kullanılır. Bir iĢlem hattın bir ucuna yazar, bir diğer ucundan okur. Örnekte bir hattın
sonuna yazma ls'ın standart çıkıĢı olarak hattın bir ucuna yazma pr'in standart girdisi
olarak bir ucundan okuma shell tarafından set edilir. pr ve lpr arasında bir kaç hat
olmalıdır.
%ls > filea
%pr < filea > fileb
%lpr < fileb
#ls'ın filea adlı dosyaya doğrudan cıkıĢı.
#filea'dan giriĢ filea'dan çıkıĢ.
#fileb'den giriĢ
ġekil 1.5 Standart GiriĢ Redirection'ı
Standart giriĢini, standart çıkıĢa çeviren ve üzerine bazı iĢlemler yapan pr bir
komut filtre diye anılır. Çoğu Unix komutu filtreler olarak kullanabilir. KarmaĢık
fonksiyonlar yaygın komutların pipelineları olarak birleĢtilebilir. Çıktı formatlama
gibi yaygın fonksiyonlar da herhangi bir program çıktısı pr ya da diğer uygun filtrelerle
birleĢtirilebildiğinden birçok komut içermeye gerek duymaz.
Unix shell'lerinin herikisi de aynı zamanda shell değiĢkenli ve genel, yüksek
seviyeli programlama dili kontrol yapılı (döngüler ve Ģart cümlecikleri) programlama
dilleridir. Bir komutun iĢletimi bir altyordam çağrısına benzer. Bir shell yazısı yani
shell komutlarının bir dosyası, onu okumak için otomatik çağrılan uygun shell ile
herhangi bir baĢka bir komut gibi iĢletilebilir. Shell programlama böylece herhangi
klasik bir dilde programlama gereği duymayan az bilinen uygulamalar için klasik
sıradan programları birleĢtirmek için kullanılır.
Bu dıĢsal kullanıcı görüntüsü Unix'in tarifi haline gelen yaygın düĢünce ve hala
çok kolay değiĢebilen tariftir. Biraz değiĢik bir imla ve semantik ile yeni bir shell yazma
200
çekirdek ya da proğramcı arayüzü bile değiĢmeksizin kullanıcının görünüĢünü oldukça
değiĢtirecektir. Örnek olarak iĢ birçok yerde Unix'ın kalbi tabii ki onun çekirdeğidir. Bu
bölümün kalan konuları onun çekirdeğini, veri yapılarını ve iĢletimi inceler. Burada
kütük sistemleri ile baĢlayacağız.
36.5. File Sistemi
Unix kütük sistemi iki ana öğeyi içerir. Kütükler ve directory'ler. Directory'ler
özel formda bir kütükten baĢka bir Ģey olmadığından Unix sisteminin ana konusu
kütüklerin gösterimidir.
36.5.1. Bloklar Ve Parçalar
Kütük sisteminin büyük bir bölümünü kullanıcının kütüklerine koymuĢ olduğu
veri bloklarını içerir. ġimdi bunların disklere nasıl yerleĢtirilmiĢ olduğunu inceleyelim.
Bir fiziksel disk sektörü genelde 512 bayttır. Fakat 512 bayttan büyük bir blok
büyüklüğü hız için daha anlamlıdır. Unix iĢletim sisteminde çok sayıda küçük kütük
bulunacağı için daha büyük bloklar çok fazla parçalanmaya sebebiyet verecektir. Bu
daha önceki 4.1BSD kütük sisteminin neden 1024 bayt blok ile sınırlandığını
açıklamaktadır.
4.2BSD modelinin bu probleme yaklaĢımı ise iki blok büyüklüğü kullanmak
olmuĢtur. Bir kütüğün tüm blokları sonuncusu dıĢında büyük blok türündendir (8192
gibi). Son blok ise kütüğü tamalayacak Ģekilde bloğun uygun bir çarpımı boyutundadır
(1024 gibi). Örneğin 18000 byte’lık bir kütük iki 8192 byte blok ve bir 2048 byte
parçadan oluĢacaktır. Tabii ki 2048 byte’ın hepsi doldurulmayacaktır.
Blok ve parça boyutları kütük sisteminin kullanılıĢ amacına göre kütük
sisteminin oluĢturulması sırasında belirlenir ve eğer çok sayıda ufak kütük oluĢacağı
sanılıyorsa parça boyutu küçük tutulmalı veya büyük kütüklerin tekrarlanan transferi
bekleniyorsa temel blok boyutu büyük tutulmalıdır. Maximum blok/parça oranının 8/1
olması ve en az blok büyüklüğünün 4096 olması beklenir. Bu verilere göre oluĢabilecek
bazı seçimler 4096/512 ve 8192/1024 olabilir.
Verilerin kütük transfer büyüklüğü 1024 byte olan, blok ve parça oranının ise
4096/512 olduğu bir kütük sisteminde bir kütüğe yazıldığını düĢünelim. Kütük sistemi
ilk transferden gelen veriyi tutabilmek için 1024 byte’lık bir parça yaratacaktır. Ġkinci
transferde ise 2048 byte’lık bir parça yaratılacaktır. Gerçek parçadaki veri bu yeni
parçaya taĢınırken ikinci 1024 byte’lık transferde bunu izlemelidir. Yaratma
algoritmaları var olan parçayı izleyen bir yer bulmaya çalıĢır ki kopyalama gerekmesin.
Fakat bu imkansız ise parçanın blok olması için yedi kopyalamaya kadar yapmak
gerekebilir. Parça kopyalamaya engel olmak için bir kütüğün blok büyüklüğünü anlayıp
o büyüklükte transfer yapabilecek proğramlar yaratılmaya çalıĢılmıĢtır.
201
36.5.2. Inode'lar
Her kütük bir index noktası tarafından gösterilir. Bir inode diskte gösterildiği
kütük hakkındaki birçok bilgiyi taĢıyan kayıttır.
Bir inode Ģunları taĢır:
1) Kütüğün kullanıcı veya grup tanımlayıcısı
2) Son günleme veya eriĢme zamanı
3) Kütüğe bağlı directoryi içeriklerinin sayısı
4) Kütüğün türü(normal kütük, direktori, sembolik bağ, karakter aygıtı,
blok aygıtı veya soket).
5) Ayrıca bir index noktası kütüğe ait veri verilerin bulunduğu blokları
belirleyen onbeĢ adet göstergeç içerir. Böylece küçük kütüklerin içerdiği veriler (12
bloktan fazla blok içermeyen) hızla eriĢilebilir. Çünkü index noktasının bir kopyası
kütük açık olduğu sürece ana bellkte tutulmaktadır.
Index noktasındaki diğer uç göstergeç ise dolaylı blokları adresler. Eğer kütük
dolaylı blok kullanacak kadar büyük ise bu göstergeçler kullanılır. Dolaylı blok
büyüklüğü ana blok büyüklüğü kadardır. Parça büyüklüğü ise sadece veri blok ları ile
ilgilendirilir.
Birinci dolaylı blok göstergeci sadece bir tane dolaylıbloğun adresini taĢır. Bu
dolaylı blok ise bir index bloğudur ve veri yerine verinin bulunduğu blokların
adreslerini taĢır. Ġkinci dolaylı blok göstergeci ise iki adet dolaylı bloğu adresler.
Bunlardan ilkinde indexlerin bulunduğu blokların adresleri ikincisinde ise verilerin
bulunduğu blokların adresleri bulunur. Sonuncu göstergeç ise üçlü dolaylı bir bloğu
adresler. Fakat buna gerek yoktur. 4.2BSD kütük sisteminde minimum blok büyüklüğü
4096 byte’tır. Böylece 322 byte büyüklüğünde kütükler dahi en fazla ikili dolaylı
bloklar ile gösterilebilir. Direk bloklar kullanılarak 49,152 byte, tek dolaylı blok
kullanılarak ise 4,299,210,752 byte’a eriĢebilir ki bu 232 byte’tan daha büyüktür. Bu
hesaplamalar her blok göstergecinin 4 byte olduğu düĢünülerek yapılmıĢtır. 232
anlamlıdır. Çünkü kütük örgüsündeki bir kütüğün göreceli adresi ana bellekte 32 bitlik
bir kelimede saklanmaktadır. 4 gigabyte birçok uygulama için yeterli bir büyüklük gibi
gözükmektedir.
36.5.3. Direktoriler
Bu aĢamada uygulamada normal bir kütük ile direktori arasında belirli bir fark
yoktur. Normal kütükler gibi direktorilerde bir index noktasıyla adreslenir ve
içerikleride olması beklenmez. Fakat direktorilerin özel bir
yapısal örgüsü
vardır.Yedinci versiyonda kütük adları 14 karakter ile sınırlı idi. Bu nedenle direktoriler
16 byte’lık yapıların listeleri Ģeklinde idiler. Bunun iki baytı index noktası sayısı için 14
byte’ı ise kütük ismi için kullanılmaktaydı.
202
4.2BSD de ise kütük isimleri 255 byte ile sınırlı olmak üzere değiĢken uzunlukta
olabilmektedir. Her yapı ilk önce kendi uzunluğunu taĢır, daha sonra kütük ismi ve
index noktası sayısı gelir. DeğiĢken uzunluktaki direktori yapısı, arama algoritmalarını
ve direktori ile uğraĢan programları zorlaĢtırsa da kullanıcıya sağladığı isim
uzunluğunun anlamlı bir limiti olmaması dolayısıyla oldukça büyük bir kolaylık
sağlamaktadır.
Her direktoride ki ilk isimler "." ve ".." 'dir. Eklenecek yeni yapı boĢ olan alana
genellikle ise var olan kütüklerin arkasına yerleĢtirilir. Kütüklerin aranması sırasında ise
lineer aramadan faydalanılır.
Kullanıcı bir kütüğe kütükadresi "pathname" ile eriĢirken kütük sistemi index
noktasını kütüğü tanımlamak için kullanır. Çekirdek sistem kullanıcı kütük adresi ile
index noktasını iliĢkilendirmelidir. Bunun için direktoriler kullanılır.
Ilk önce baĢlangıç direktorisi tespit edilir. Eğer kütükadresinin ilk karakteri "/"
karakteri ise baĢlangıç noktası kök direktoridir. Bu karakterden baĢka birĢeyle baĢlıyorsa
baĢlangıç direktorisi o anda o anda bulunan direktoridir. BaĢlangıç direktorisinin var
olup olmadığı, uygun kütük türü, eriĢime imkan tanınıp tanınmadığı, kontrol edilerek
gerekiyorsa bir hata mesajı dönderilir. BaĢlangıç direktorisinin index noktası her an
eriĢilebilir durumdadır.
Kütükadresinin izleyen elemanı "/" 'den sonra veya kütükadresinin sonunda
kütük ismi bulunmaktadır. BaĢlangıç direktorisinde bu kütük ismi aranır ve eğer
bulunmazsa hata mesajı dönderilir. Eğer kütükadresinde baĢka bir eleman varsa, bu
halde index noktası bir direktoriyi gösteriyor olmalıdır aksi halde hata mesajı aranır ve
bu iĢleme kütükadresinin sonuna kadar devam edilir ve istenen index noktası gönderilir.
Disk kütüğü olmayan aygıtlar için disk üzerinde yer ayrılmamıĢtır. Çekirdek
sistem bu kütük tiplerini tanıyarak gerekli aygıt tanımlayıcılarını çağırıp giriĢ çıkıĢ
iĢleminin gerçekleĢmesini sağlar.
Index noktası bulunduktan sonra kütüğü açmak için bir sistem çağrımı yapılır.
Bir kütük yapısı yaratılarak index noktası göstermesi sağlanır. Kullanıcıya verilen kütük
tanımlayıcısı iĢte bu kütük yapısıdır.
36.5.4. File Tanımlayıcısının Inode'a Bağlanması
Sistem çağrımlarında açık bir kütükle ilgilenen çağrımlara kütüğün tanımlayıcısı
argüman olarak geçirilir. Kütük tanımlayıcısı ise çekirdek sistem tarafından yapılan
iĢlemde açık kütükleri indexlemek için kullanılır. Açık kütüklerin listesindeki her
eleman bir kütük yapısını gösteren index taĢır. Bu kütük yapısıda index noktasını
gösteren bir göstergeç taĢımaktadır.
Oku ve yaz sistem komutları argüman olarak kütükte bir adresi istemezler. Bu
iĢlem sistem tarafından kütüğün göreceli adresi kullanılarak gerçekleĢtirilir. Yapılan
okuma ve yazmanın büyüklüğüne göre ise bu adres günlenir. Bu adres istenirse bir
203
sistem çağrısı ile istenilen değer atanır. Eğer kütük tanımlayıcısı kütük göstergeci yerine
bir index noktası matrisini adresleseydi bu göreceli kütük adresi kütük noktasında
tutulmak zorunda kalacaktı. Birçok iĢlem aynı kütüğü açıp eriĢebileceğine göre de
hepsini aynı göreceli adrese sahip olabilmesi açısından index noktasında adresin
tutulması doğru değildir. Bu nedenle kütük yapısı bu adresi tutar.
Kütük yapısının gösterdiği index noktası listesi disktekinin bir kopyasıdır.Yalnız
bazı fazla bilgileride taĢır. Örneğin kaç tane kütük yapısının onu gösterdiği v.b. Kütük
yapısıda benzer bir sayı sahasına kütük tanımlayıcıları için sahiptir.
36.5.5. Disk Yapıları
Kullanıcının gördüğü kütük sistemi, yoğun bir bellek aleti (genellikle bir
disk) üzerindeki veri ile desteklenir. Kullanıcı umumiyetle sadece bir kütük ismini
bilir, fakat bu mantıksal kütük sistemi gerçekte, herbiri farklı bir alet üzerinde olan
pek çok fiziksel kütük sisteminden oluĢabilir. Aygıt karakteristiksel özellikleri farklı
olduklarından, her farklı donanım aleti kendi fiziksel kütük sistemini tanımlar. Aslında
genel olarak diskler gibi büyük fiziksel aletleri bölmek (diskleri, çoklu mantıksal
aletlere bölmek) arzu edilen bir olaydır. Her mantıksal aygıt bir fiziksel kütük
sistemini tanımlar. ġekil-96'da kütük sistemlerinin directory yapısını nasıl teĢkil
ettiği gösterilmiĢtir. Bu kütük sistemleri üzerinde fiziksel aygıtların bölümleri olan
mantıksal aygıtlar resimlendirilmiĢtir.
Bir fiziksel aygıtın çoklu kütük sistemlerine bölünmesinin pek çok faydası
vardır. Farklı kütük sistemleri farklı kullanımları destekleyebilir. Pek çok bölme
(partition) kütük sistemi tarafından kullanabilinir olmasına rağmen, en azın dan biri
görüntü bellek yazılımında kullanılan bir değiĢtirme alanı (swap area) için gereklidir.
Böylece, olabilecek yazı hasarı sadece bir kütük sistemi ile sınırlandırıldığı için,
güvenilirlikte geliĢtirilmiĢtir. Her bölüm için kütük sistemi paremetrelerini (blok veya
kısım (fragment) boyutlarını) değiĢtirerek etkinlik geliĢtirilebilinir. Aynı zamanda ayrı
kütük sistemlerinde, kütükler, kütük sistemleri boyunca bölünmeyeceğinden bir
programın geniĢ bir kütük için mevcut bütün yeri kullanması önlenir.
Bir sürücü üzerindeki kütük sistemlerinin gerçek sayısı disklerin hacmine ve bir
bütün olarak bilgisayar sisteminin amacına göre değiĢir. Bir kütük sistemi (kök kütük
sistemi) her zaman mevcuttur. Diğerleri kök kütük sisteminin directory hiyerarĢisine
monte edilebilir.
INODE yapısındaki bir bit, Inode'un üzerine bir kütük sisteminin monte
edildiğini gösterir. Bu kütüğe konan iĢaret, mount table'a monte edilen aygıtın
numarası, monte edilen kütük sisteminin kök dırectory Inode 'unu bulmak için
kullanılır. Bunun tersi olarak, eğer bir yol isim (pathname) elemanı ''. .'' ve araĢtırılan
directory, kurulan kütük sisteminin kök directory'si ise üzerinde kurulan Inode'u
bulmak için mount table araĢtırılmalıdır ve sonuçta bu Inode kullanılır.
204
Her kütük sistemi ayrı bir sistem kaynağıdır ve bir grup kütüğü ifade eder.
Mantıksal aygıt üzerindeki ilk sectör boot bloktur. Bu, aynı zamanda ana bootstrap
programını içeren boot bloktur. Ana bootstrap programı, sonraki 7.5 K byte' da kalan
ikinci bir bootstrap programını çağırmak için kullanılır. Süper-block, kütük
sisteminin statik parametrelerini içerir. Bunlar:
- Kütük sisteminin toplam hacmini
- Veri bloklarının blok ve kısım boyutlarını
- Bellek atama politikasını etkileyen sınırlandırılmıĢ parametreler
içerir.
root
swap
fiziksel aygıtlar
Mantıksal kütük
sistemi
kütük sistemleri
Mantıksal
aygıtlar
Şekil-96. Mantıksal Kütük Sistemlerinin Fiziksel Aygıtlarla Eşleştirilmesi
36.5.6. Yürütmeler (Implementations)
Kütük sisteminin kullanıcı ara yüzü basit ve iyi tanımlanmıĢtır. Bu,
kullanıcı üzerinde
belirli bir etki yapmadan kütük sistemi yürütmesinin
değiĢtirilmesine izin verir. Kütük sistemi version 6 ile version 7 arasında ve yine
version 7 ile 4BSD arasında değiĢtirildi. Version 7 için inode'ların hacmi iki katına
çıkarıldı, maksimum kütük ve kütük sistemi hacimleri
arttırıldı, ve free-list
yönetimi detayları ile süperblok bilgileri değiĢtirildi. Aynı anda geniĢ kütüklerdeki
205
ofsetleri tam olarak belirlemeyi mümkün kılmak için seek (16-bit offset'li) 1seek (32
bit offset'li) oldu. Fakat bunun dıĢında bazı diğer değiĢikler çekirdeğin dıĢında
görülebildi.
4.0BSD kütük sisteminde kullanılan blokların hacmi 512 byte'dan 1024
byte'a çıkarıldı. Her ne kadar bu, disk üzerinde içsel dağılma artıĢı ürettiyse de, esas
olarak her disk transferi üzerinde daha fazla veri eriĢiminden dolayı doğrudan yazma
(throughput) iki katına çıktı. Bu fikir ve aygıt sürücüleri ile programlar hakkında diğer
bazı fikirler daha sonra SYSTEM V üzerinde uygulandı.
36.5.7. Layout Ve Atama Politikaları
Çekirdek bir kütüğü belirlemek için mantıksal aygıt numarası ile inode
numarası çiftini kullanır. Mantıksal aygıt numarası, ilgili kütük sistemini tanımlar.
Kütük sitemindeki inode'lar sıra ile
numaralandırılırlar. Version 7'deki kütük
sistemindeki bütün inode lar, inode'ları takip eden veri blokları ile ve
mantıksal aygıtın baĢındaki tek bir süper bloğun hemen ardındaki bir dizindedirler.
INUMBER bu diziye sadece etkili bir indextir.
Version 7 file sistemlerinde, bir kütüğün bir bloğu disk üzerinde Inode
dizisinin sonu ile kütük sisteminin sonu arasında herhangi bir yerde olabilir. Serbest
bloklar (free blocks) süper bloğun içinde bulunan bir linked list (bağlı liste) içinde
tutulurlar. Bloklar free list'in önüne yığılırlar ve yeni kütükler ya da mevcut kütükleri
geniĢletmek için gerektiğinde buradan alınırlar. Bu yüzden bu kütüğün blokları, Inode
ve birbirlerinden rastgele uzakta olabilirler. Bundan baĢka bu Ģekilde ne kadar çok
kütük sistemi kullanılırsa, bir kütükte o kadar çok düzenlenmiĢ blok oluĢur. Bu iĢlem
bütüm kütük sistemini ele alıp saklamakla tersine çevrilebilir. Ancak bu uygun bir yol
değildir.
Diğer bir zorluk da kütük sistemlerinin güvenirliliğidir. Hiz açısından her
kurulan kütük sistemlerinin süper bloğu bellekte tutulur. Bu, özellikle Free-List'in
kullanılıĢı için, çekirdeğin bir süper bloğa çabukça eriĢmesine izin verir. In-Core ve
disk kopyelerini eĢ zamanlı (synchronized) tutmak için, her 30 saniyede, süper blok
diske yazılır. Buna rağmen sistem hataları ya da donanım baĢarısızlıkları için, bir
sistemin bozulması sırasında In-Core (bellek teki) süper bloğu yok etmek bazen
olası bir olaydır. Bundan sonra free list kaybolur ve ancak kütük sistemindeki bütün
blokların uzunca bir süre araĢtırılmasıyla tekrar kurulabilir.
4.2BSD kütük sistemi yürütmesi, version 7'nin kütük sistemi yürütmesinden
tamamıyla farklıdır. Bu yeniden yönlendirme öncelikle etkinlik ve kuvvet için
yapıldı. Buna benzer pek çok değiĢiklik de çekirdeğin dıĢından görülemez. Aynı
zamanda sistem kullanıcı ve çağrı seviyesinde de görülebilen sembolik listeler ve uzun
kütük isimleri (255 karaktere kadar) gibi diğer bazı değiĢiklikler de yapıldı. Bu
206
özellikler için gerekli olan pek çok değiĢikler çekirdekte değil, ancak onu kullanan
programlar da yapıldı.
Yer ataması özellikle farklıdır. 4.2BSD'deki baĢlıca yeni kavram silindir
grubudur. Silindir grubu, diskin silindir grubuna eriĢimini minimum disk kafası
hareketi gerektirecek Ģekilde, birbirini takip eden bir ya da birden fazla silindirler
üzerinde bulunur. Her silindir grubunun bir süper bloğu, bir silindir bloğu, bir inode
dizisi ve bazı veri blokları vardır.
Veri
Blokları
Super Blok
Silindir Blok
Inode'lar
Veri Blokları
Şekil 1.8
4.2 BSD Silindir Grubu
Süper blok her silindir grubunda farklıdır. Bu yüzden disk bozulması
durumunda herhangi biri yeniden elde edilebilir. Silindir blok, belirli silindir grubunun
dinamik parametrelerini içerir. Bunlar serbest veri blokları ve kısımlarının (fragments)
bir bit map'ini ve serbest Inode'larının bir bit map'ini içerir. Aynı zamanda bellek atama
stratejilerinin son gelismeleri hakkındaki istatistikler de burada tutulur.
Bir silindir grubundaki (super blok, silindir blok ve inodelar) baĢlık (header)
bilgisi her zaman silindir grubunun baĢında degildir. Eğer öyle olsaydı, her silindir
grubu icin baĢlık (header) bilgisi aynı disk plakası üzerinde olabileceginden, bir tek disk
kafasının bozulması (crash) ile, bu baĢlık bilgilerinin tümü yok olabilirdi. Bu yüzden
her silindir grubunun baĢlık bilgileri, grubun baĢından farklı offsetlerde bulunur.
Genelde directory listeleme komutu olan ls'nin okuması için bir directory'deki
her kütüğün inode'larının birbirine yakın olması istenir. Bu yüzden bir kütük için inode
genellikle esas (parent) directory'nin Inode 'u olarak aynı silindir grubundan tahsis
edilir. Ancak her Ģey yerleĢtirilemez. Yine de yeni bir directory'nin inode'u kendi
directory grubundan farklı bir yere konur. Böyle yeni bir directory Inode 'u için seçilen
silindir grubu, kullanılmayan inode'ların en büyük numaralısıdır.
Bir kütüğün veri bloklarına eriĢim ile ilgili olan disk kafasının haraketlerini
azaltmak icin, bloklar mümkün olduğunca aynı silindir grubundan ayrılırlar. Bir tek
kütügün, bir silindirin tüm bloklarını ele almasına izin verilemeyecegiden belirli bir
hacmi örnegin 32K byte'i geçen bir kütügün farklı bir silindir grubuna yöneltilmesi
yapılır. Bu yeni grup ortalamadan daha fazla serbest alanları olanlar arasından seçilir.
207
Eğer kütük büyümeye devam ediyorsa, (her megabyte da) bellek tahsisi yine baĢka bir
silindir grubuna yöneltilir. Bu yüzden küçük bir kütüğün tüm bloklarının aynı silindir
grubunda olması daha olasıdır. Ayrıca genis bir kütüge eriĢimle ilgili arayıĢların sayısı
küçük tutulur.
Disk blok dağıtımı iĢinde iki seviye vardır. Genel politika rutinleri, istenen bir
disk bloğunu yukarıdaki düĢünceye göre seçer. Yerel politika rutinleri, istenilen bloğun
yanındaki bir bloğu seçmek için, silindir bloğunda kayıtlı özel bilğileri kullanırlar. Talep
edilen blok kullanımında degilse, bunu geri gönderir. Aksi taktirde, seçilen blok,
istenilen bloğa aynı silindirde ya da farklı bir silindirin bir bloğunda dönel (rotational)
olarak yakındır. Yine de aynı silindir grubu geri döner. Eğer silindir grubunda daha fazla
blok yoksa öteki tüm silindir grupları arasında bir blok bulmak için ikinci dereceden bir
araĢtırma daha yapılır. ġayet kütük sisteminde yeterli miktarda (tipik olarak %10) boĢ
alan varsa genellikle bloklar arzu edilen yerlerde bulunurlar. Bundan dolayı dörtlü
REHASH ve yorucu araĢtırmalar yapılmaz ve kütük sisteminin performansı
kullanılmayla düĢmez.
7. Versiyon kütük sistemi %3 veya daha azını kullanmasına rağmen 4.2BSD
sistemi tipik bir diskin band geniĢliginin %30 veya daha fazlasını kullanma kapasitesine
sahiptir.
36.6. ĠĢlem Yöneticisi
ĠĢletim sistemi tasarımında en önemli problemlerden biri iĢlemlerin gösterimidir.
Unix ile diğer pek çok sistem arasındaki en önemli farklardan biri birden çok iĢlemin
yaratılması ve iĢlenmesindeki kolaylıktır. Bu iĢlemler, Unix'te çeĢitli kontrol blokları ile
gösterilirler. Bir kullanıcı iĢleminin görüntü adres boĢluğunda eriĢilebilir hiç bir sistem
kontrol bloğu yoktur. ĠĢlemle ilgili kontrol blokları 'kernel'da saklanırlar. Bu kontrol
bloklarındaki bilgi, kernel tarafından iĢlem kontrolu ve CPU scheduling iĢleminde
kullanılır.
36.6.1. ĠĢlem Kontrol Blokları
ĠĢlemlerle ilgili temel veri yapısı, iĢlem yapısı (process structure)'dir. Bir iĢlem
yapısı, iĢlemin tanımlayıcısı, scheduling bilgisi (örneğin iĢlemin önceliği) ve diğer
kontrol bloklarına olan pointer'lar gibi, bir iĢlem degiĢtirildiğinde hakkında bilinmesi
gerekli herĢeyi içerir. ĠĢlem yapılarının, uzunluğu sisteme bağlanma zamanında
tanımlanmıĢ bir dizisi vardır. Hazır iĢlemlerin iĢlem yapıları, schedular tarafından çift
bağlı bir listede bağlı olarak tutulurlar ve her iĢlem yapısında iĢlemin parent'ina,
varolan en küçük childına ve aynı program kodunu paylaĢan iĢlemler listesi gibi diğer
ilgili birimlerine pointerlar vardır.
Bir kullanıcı iĢleminin 'görüntü adres boĢluğu (virtual adress space)', metin
(program kodu), veri ve stack segmentleri olarak bulunmuĢtur. Veri ve stack
segmentleri, daima aynı adres boĢluğundadırlar. Fakat ayrı ayrı ve de genellikle aksi
yönlerde geniĢlerler; çogunlukla stack aĢağı doğru, veri de yukarı, stack'a doğru geniĢler.
208
Metin segmenti bazen (FDP-11 deki gibi ayrı komutlu ve ayrı veri boĢluklu olarak) veri
ve stack'ten farklı bir adres boĢluğundadır. Genellikle salt okunurdur.
PaylaĢılabilir metinli her iĢlem (4.2BSD'de hemen hepsi) iĢlem yapısında 'metin
yapısı (text structure)'ni gösteren bir pointer'a sahiptir. Metin yapısı, metin segmenti kaç
tane iĢlemin kullanmakta oldugunu, bunların iĢlem yapılarının listesini gösteren bir
pointer'i ve değiĢtirilen metin segmenti sayfa tablosunun diskte nerede bulunabilecegini
tutar. Metin yapısını kendisi daima ana bellekte kalıcıdır. Bu tür yapıların dizisi sisteme
bağlama zamanında tahsis edilir. ĠĢlemlerin metin veri ve stack segmentleri
degiĢtirilebilir. Segmentler degiĢtirildiklerinde sayfalanırlar.
Sayfa tabloları (page tables) iĢlemin görüntü belleğinden fiziksel belleğine olan
eĢlemeye (mapping) ait bilgiyi tutarlar. ĠĢlem yapısı, iĢlem ana belllekte kalıcıyken
kullanılan ve sayfa tablosunu gösteren pointer'ları veya iĢlem değiĢtirilirken kullanılan
değiĢtirme aygıtındaki iĢlemin adresini içerir. PaylaĢımlı bir metin segmenti için ayrı ve
özel bir sayfa tablosu yoktur; segmenti paylaĢan her iĢlem, iĢlemin sayfa tablosundaki
sayfaları için giriĢlere sahiptir.
ĠĢlem kalıcı olduğunda, iĢlem hakkında ihtiyaç duyulan bilgi iĢlem yapısında
degil, 'kullanıcı yapısı(user structure)'unda (u yapısı) saklanır. U yapısı, kernel görüntü
veri boĢluğuna eĢlenmiĢtir. VAX iĢlem kontrol bloğunun bir kopyesi, iĢlem çalıĢmaz
iken genel register'larını, stack pointer'ini, program sayacını ve sayfa tablosu base
register'larını saklamak üzere burada saklanır. Sistem çağırma parametrelerini ve dönüĢ
değerlerini saklamak içinde yerler vardır. ĠĢlemle ilgili tüm kullanıcı ve grup
tanımlayıcıları (sadece iĢlem yapısında saklanan efektif kullanıcı tanımlayıcısı degil)
burada saklanırlar. Sinyaller, zamanlayıcılar ve kotaların veri yapıları buradadır. Normal
kullanıcıyı daha çok ilgilendiren directory ve açık kütükler tablosu da kullanıcı
yapısında tutulurlar.
Her iĢlemin bir kullanıcı ve birde sistem evresi vardır. Çoğu normal iĢ, 'kullanıcı
iĢlemi (user procces)' tarafından yapılır. Fakat bir sistem çagrısı gerçekleĢtiğinde sistem
çagrısını izleyen, 'sistem iĢlemi (system process)'dir. Bir iĢlemin sistem ve kullanıcı
evreleri aynı anda iĢlemezler. Sistem iĢleminin, kullanıcı iĢlemininkinden farklı bir
stack'ı vardır. ĠĢlemin 'kernel stack'ı kullanıcı yapısının hemen ardından gelir. Kernel
stack ve kullanıcı yapısı ,beraberce iĢlemin 'sistem veri segmenti (system data
segment)'ni oluĢtururlar.
ġekil-97 iĢlemin çeĢitli bölümlerini bulmak için iĢlem yapısının nasıl
kullanıldığını göstermektedir.
Fork sistem çağrısı, child iĢlem için yeni bir iĢlem yapısı açar (yeni bir iĢlem
tanımlayıcısı ile birlikte) ve kullanıcı yapısını kopyalar. Normal olarak, yeni bir metin
yapısına gerek yoktur, çünkü iĢlemler metinlerini paylaĢmaktadırlar. Uygun sayaçlar ve
listeler de günlenirler. Yeni bir sayfa tablosu oluĢturulur ve child iĢlemin veri ve stack
segmentleri için ana bellekte yer açılır. Kullanıcı yapısının kopyalanmıĢ olması, iĢlemin
açık kütük belirteçlerini, kullanıcı ve grup tanımlayıcılarını, sinyal sistemlerini ve diger
benzer özelliklerini korur.
209
kullanıcı
yapısı
proses
yapısı
kernel
stack
sistem veri yapısı
stack
metin
yapısı
kalıcı tablolar
veri
metin
kullanıcı boşluğu
değiştirilebilir işlem görüntüsü
Şekil-97. CPU Scheduling Bölümleri
vfork sistem çağrısı, veri ve stack'nı yeni iĢleme kopyalamaz. Bunun yerine yeni
iĢlem eskisinin sayfa tablosunu paylaĢır. Ancak, yeni bir kullanıcı yapısı ve yeni bir
iĢlem yapısı yine yaratılır. Bu sistem çağrısının sık karĢılaĢılan bir kullanımı, bir shell ile
bir komutu iĢletmek ve tamamlanmasını beklemektir. Parent iĢlem vfork'u child iĢlemi
oluĢturmak için kullanır. Child iĢlem, görüntü adres boĢlugunu tamamen degiĢtirmek
üzere hemen bir execve 'kullanmak istediğinden parent iĢlemin bütün bir kopyasına
gerek yoktur. Pipe'ları iĢlemek için gerekli olan bu tür veri yapıları vfork ile execve
arasındaki regiter'larda tutulabilirler. Bir iĢlemde kütükler, diger bir iĢlemi etkilemeden
kapatılabilirler, çünkü ilgili kernel veri yapıları, paylaĢılmayan kullanıcı yapısına
bağlıdır. Parent, child'ın ihtiyacı olan ana bellek alanını degiĢtirmemek için, child
bitene kadar iĢletimini durdurmak üzere wait'ini kullanır.
Parent iĢlem büyük olduğunda, vfork sistem CPU zamanında önemli kazançlar
sağlanabilir. Bununla beraber, execve ortaya çıkana kadar her iki iĢlemde bellek
değiĢiklikleri olabileceğinden oldukça tehlikeli bir sistem çagrısıdır. Bir baĢka
alternatif, sayfa tablosunu kopyalayarak tüm sayfaları paylaĢmak, fakat her iki sayfa
tablosunun giriĢlerinide 'copy on-write' olarak iĢaretlemektir. Donanım korunma bitleri,
bu paylaĢılmıĢ sayfalara bir yazma istemi olduğunda set edilirler. Böyle bir durumda,
yeni bir çerçeve açılır ve paylaĢılmıĢ sayfa bu yeni çerçeveye kopyalanır. Sayfa tabloları,
bu sayfanın artık paylaĢılmıĢ olmadıgını(ve bu yüzdende yazma-korumalı olmaya artık
ihtiyacı olmadıgını) göstermek üzere düzeltilirler ve iĢletim tekrar devam edebilir.
VAX/750'deki donanım hataları, 4.2BSD'nin bir copy-on-write fork iĢlemi içermesini
engellemiĢtir.
Bir execve sistem çagrısı, yeni bir iĢlem veya kullanıcı yapısı yaratmaz. Bunun
yerine, iĢlemin metin ve verileri tekrar yerine konurlar. Açık kütükler korunurlar (hem
de bir execve çağrısı üzerine bazı kütük belirteçlerinin kapanması gerektigini
belirtmenin bir yolu olduğu halde). Çoğu sinyal iĢleme özellikleri korunur, fakat belirli
210
nedenlerden ötürü, bir sinyal aracılığıyla özel bir kullanıcı rutininin çağrılması ile ilgili
düzenlemeler silinir.
36.6.2. CPU Scheduling
Unix'te 'CPU scheduling' interactivite iĢlemlerinin yararı için tasarlanmıĢtır.
CPU bağımlı iĢler için round-robin'i azaltan bir öncelik algoritması tarafından
iĢlemlere küçük CPU zaman dilimleri verilir.
Her iĢlemin, ilgili bir scheduling önceligi (scheduling priority) vardır. Büyük
rakamlar daha düĢük önceliktedir. Diskten g/ç yapan iĢlemlerle diğer önemli iĢlemlerin
negatif öncelikleri vardır ve sinyallerle ortadan kalıdırılamazlar. Normal kullanıcı
iĢlemlerinin pozitif öncelikeri vardır, dolayısıyla sistem iĢlemlerinden daha sonra
çalıĢtırılırlar. Ancak kullanıcı iĢlemlerinin birbirlerine öncelikleride vardır. Bu iĢ
'nice' komutu ile sağlanır.
Bir iĢlem ne kadar çok CPU zamanı harcıyorsa, önceligi o kadar düĢer (o kadar
pozitiftir). Bunun terside geçerlidir. Bu yüzden, CPU scheduling iĢleminde negatif geri
besleme vardır ve bir tek iĢlemin bütün CPU zamanını kapsaması zordur. Bu tür zaman
açıgını önlemek üzere iĢlem yaĢlandırma uygulanır .
Eski Unix sistemleri round-robin scheduling iĢlemi için bir saniyelik bir birim
kullanıyorlardı. 4.2BSD iĢlemleri her 1/10 saniyede bir yeniden planlar ve her saniyede
birde öncelikleri yeniden hesaplar. Round-robin scheduling iĢlemi, 'time out'
mekanizması tarafından gerçekleĢtirilir. Bu, saat kesinti sürücüsüne belirli bir aralıktan
sonra bir kernel alt yordamı çağırmasını söyler; bu durumda çagrılacak altyordam,
tekrar schedulingyi yapar ve sonra kendisini tekrar çağırmak üzere bir 'timeout' verir.
Önceliklerin tekrar hesaplanması da kendisi için bir 'timeout' veren bir alt yordam
tarafından zamanlanır.
Kernelde iĢlemler, birbirine üstünlük kurmazlar. Bir iĢlem, G/Ç bekledigi ya da
zaman dilimi bittigi için
cpu'yu bırakabilir. Bir iĢlem cpu'yu bırakmaya karar
verdiğinde
bir 'event(olay)' üzerine sleep yapar. Bunun için kullanılan kernel
düzeneğine ''sleep' denir (kullanıcı seviyesindeki aynı adlı kütüphane yordamıyla
karıĢtırılmamalıdır). Olay olduğunda onu bilen sistem iĢlemi, olaya karĢılık gelen
adresle birlikte 'wakeup'i çağırır ve aynı adreste bir sleep yapmıĢ tüm iĢlemler
çalıĢtırılmak üzere hazır kuyruğuna konurlar.
Örnegin, diskten G/Ç iĢleminin tamamlanmasını bekleyen bir iĢlem, transfer
edilmekte olan veriye karĢılık gelen buffer header'ında sleep yapar. Disk sürücünün
kesinti yordamı transferin tamamlandıgını bildirince buffer header'ında 'wakeup 'ı
çagırır. Kesinti, kernel stack'ını o anda çalıĢmakta olan iĢlem için kullanır ve 'wakeup' o
sistem iĢleminde yapılır.
Gerçekte çalıĢmakta olan iĢlem, scheduler tarafından seçilir. 'Sleep', bu amaçla,
scheduling önceliğini ikinci bir argüman olarak alır. Bu öncelik argümanı, eğer
211
negatifse, aynı zamanda iĢlemin sinyal gibi özel bir olay tarafından uyarılmasınıda
önler.
Bir sinyal üretildiginde, etkilenen iĢlemin sistem yarısı çalıĢana kadar sinyal
kuyruklanır. Bu genellikle çabuk olur, çünkü sinyal normalde baĢka bir Ģart bekleyen
iĢlemin uyarılmasını saglar.
Olaylar (events)'la ilgili bellek yoktur ve olayın üzerinde bir 'sleep' yapan
yordamın çağırıcısı, bekleme nedeninin geçerliliğini yitirmesi olasılığını da göz önüne
alarak, zamanından önce bir dönüĢe karĢı hazırlanmalıdır.
Olay (event) mekanizmasıyla ilgili 'race conditions (yarıĢ koĢulları)' vardır. Eğer
bir iĢlem (örneğin bellekteki bir bayrağı kontrol etmesinden ötürü) bir olay üzerinde
sleep etmek isterse ve olay da, iĢlem sleep'i gerçekleĢtirecek düzeneği çalıĢtıramadan
oluĢursa, iĢlemin sleep'i sonsuza dek sürebilir. Kesinti oluĢmaması ve yalnız olayı
isteyen iĢlemin sleep yapana kadar çalıĢabilmesi için, bu durum, kritik bölge boyunca
donanım iĢlemci önceligini yükselterek önlenir. Donanım iĢlemci önceligi, böylece
kernel boyunca kritik bölgeleri korumak üzere kullanılır. Bu olay Unix'in çoklu
iĢlemcili makinelere taĢınabilmesini engelleyen en önemli faktördür.
Metin editörü gibi bir çok iĢlem, G/Ç-bağımlıdır ve genellikle G/Ç bekleyecek
Ģekilde planlanlanırlar. Deneyimler göstermiĢtir ki, Unix schedular'ı en iyi G/Ç-bağımlı
iĢleri baĢarır. Bu, metin formatlayıcılar veya dil yorumlayıcıları gibi cpu-bağımlı iĢlerin
çalıĢmasında gözlenebilir.
Öncelik mekanizmasının geri-besleme özelliğinin biraz uzun-vadeli scheduling
sağlamasına (çünkü büyük ölçüde uzun-vadeli iĢ karıĢımı (job mix) sağlar) rağmen,
burada cpu scheduling adıyla bahsedilen, 4.Bölümde'deki kısa-vadeli scheduling (shortterm scheduling) karĢılık gelir. Orta-vadeli scheduling (medıum term scheduling) ise
aĢağıda anlatılan değiĢtirme mekanizmasıyla yapılır.
36.7. Bellek Yönetimi
Unix'in ilk geliĢmelerinin çoğu bir PDP-11 üzerinde olmuĢtur. PDP-11, görünür
adres boĢlugunda herbiri en fazla 8192 byte olan sadece sekiz segmente sahiptir. PDP11/70 gibi büyük makinalar etkin bir Ģekilde adres boĢluğunu ve segment sayısını iki
katına çkaran ayrık komut ve adres bosluklarına izin verirler. Fakat bu olay halen fazla
değildir. Buna ilaveten, bir veri segmentinin kesinti vektörlerine, diğerinin per-process
iĢlem sistem veri segmentine ve bir diğerinin de UNIBUS kayıtçılarına adanmıĢ
olmasından dolayı, çekirdek genellikle ciddi bir Ģekilde zorlanmaktaydı. Dahası küçük
PDP-11' lerde toplam fiziksel bellek 256 Kbyte ile sınırlanmıĢtı. Toplam bellek
kaynakları, karmaĢık bellek yönetim algoritmalarını haklı göstermek ve desteklemek
için elveriĢsizdi. Çünkü Unix tüm iĢlem bellek görüntüsünü değiĢtirmektedir.
36.7.1. DeğiĢtirme(Swapping)
212
Pre-3BSD sistemleri iĢlemler arasında bellek içerigini tutmak için sadece
swapping'i kullandılar. Eğer çok fazla içerik varsa, yeterli bellek sağlanıncaya kadar
iĢlemler dıĢarıya çıkarılır. Ayrıca, biraz büyük iĢlemler küçük iĢlemleri bellek dıĢına
çıkmaya zorlayabilirler. Sistem veri segmenti (u yapısı ve çekirdek stack'ı) ve kulanıcı
veri segmenti (text paylaĢılamaz ise, veri ve stack) değiĢim transfer etkinliği için arka
arkaya gelen ana bellekte tutulurlar. Bundan dolayı belleğin harici parçalanması
(fragmantasyanu) ciddi bir problem olabilir.
Ana bellek ve değiĢim boĢluklarının tahsisi ilk uygun yerde yapılır. Bir iĢlemin
bellek görünüm miktarı arttıkça (ya stack geniĢlemesinden ya da veri geniĢlemesinden)
tüm görünüm için yeterli büyüklükte olan yeni bir bellek parçası açılır. Bellek
görünümü kopyalanır, eski bellek serbest bırakılır ve uygun tablolar günlenir. Bazı
sistemlerde kopyalamayı engellemek amacı ile bütünleĢik bellek alanı bulmak için bir
çaba harcanır. Eğer yeterince büyük tek bir ana bellek parçası yoksa yeni miktarla
içeriye geri alınabilecek bir Ģekilde iĢlem dıĢarıya çıkarılır.
Sadece okunabilir olduğu için paylaĢılabilir text segmentinin değiĢimine gerek
yoktur. Çekirdekte baĢka bir istek olduğunda paylaĢılabilir text segmentinde bir
iĢlem için okuma yapmaya da gerek yoktur. Bu, paylaĢılabilir text segmentleri ile iliĢkiyi
kesmemenin ana nedenlerinden biridir:Az değiĢim trafiği. Diğer bir neden de ana text
segmenti kullanan coklu iĢlemlerin ihtiyacı olan ana bellek miktarının kısıtlı olmasıdır.
Hangi iĢlemin dıĢarıya ve içeriye alınacağı konusundaki karar schedular
tarafından verilir. ĠĢlem 0 (sıfır, swapper iĢlemi olarak da bilinir). Scheduler, dıĢarıya
veya içeriye alınacak iĢlemleri en az dört saniyede bir kontrol eder. Bir iĢlem boĢ ise,
uzun süredir ana bellekte ise veya büyükse dıĢarıya alınır, uzun bir süredir dıĢarıda ise
veya küçük ise de içeriye alınır. Dağılmayı önlemek için kontroller vardır (temel olarak
belirli bir zaman süresince çekirdekte değilse bir iĢlemin çıkarılmasına izin
verilmeyerek).
Eğer iĢlerin dıĢarıya çıkarılmasına ihtiyaç duyulmuyorsa içeriye alınacak bir
iĢlem bulmak için iĢlem tablosu taranır (ne kadar küçük olduğu ve ne kadar süre ile
dıĢarıya alınacağı belirlenir). Eğer yeterli bellek yoksa, oluncaya kadar iĢlemler
dıĢarıya alınır.
4.2BSD'de değiĢim boĢlukları, disk üzerindeki boĢluk partisyonunun miktarı
tarafından belirlenen bir maksimuma kadar ikinin katları ve minumum olacak Ģekilde
atanırlar. Bundan dolayı, değiĢim için birden çok mantıksal disk partisyonu
kullanılacaksa bunlar aynı ölçüde olmak zorundadırlar. Ayrıca bu mantıksal disk
partisyonları disk aramalarını minumum yapmak için ayrı disk kolları üzerinde
olmalıdırlar.
Çoğu Unix sistemleri hala yukarıda belirtilen degiĢim tasarısını
kullakmaktatırlar. Sistem V'de dahil olmak üzere tüm USG sistemleri bunu kullanırlar.
Diğer yandan 4.2BSD'yi de içeren tüm Berkeley Unix sistemleri öncelikle bellek içerik
yönetimi için sayfalamayı kullanırlar, ikinci olarakta değiĢimi kullanırlar.
213
36.7.2. Sayfalama(Paging)
Berkeley Unix'e sayfalamayı 3BSD ile takdim etti. 4.2BSD bir istenebilir sayfalı
görünür bellek sistemidir. Sayfalama ile belleğin harici parçalanması ortadan kaldırıldı.
(KuĢkusuz dahili parcalanma var, ama küçük sayfa ölçüleri ile ihmal edilebilir).
Tamamı kalıcı olmak zorunda olmadığından daha çok iĢ ana bellekte tutulabileceği için
değiĢim minumum seviyede tutulabilir.
Ġstenebilir sayfalama basit bir tarzda yapılır. Bir iĢlem bir sayfaya ihtiyaç
duyduğunda sayfa yoksa, çekirdekte bir hatası ortaya çıkar, bir ana bellek iskeleti
atanır ve disk sayfası içeriye okunur.
Eğer ihtiyaç duyulan sayfa, iĢlem için hala sayfa tablosunda ise ve sayfa yerleĢim
iĢlemi tarafından geçersiz olarak iĢaretlenmiĢse, geçerli olarak iĢaretlenebilir ve
herhangi bir G\Ç transferi olmadan kullanılabilir. Sayfalar aynı Ģekil de serbest yapı
listelerinden geri alınabiirler. Birden fazla iĢlem baĢladığında, iĢlem sayfalarının çoğu
önceden sayfalanır ve bu mekanizma tarafından düzenleme için serbest listelere
konulurlar. BaĢlangıçta ön sayfalamayı önlemek amacıyla bir iĢlem için düzenlemeler
yapılabilir. Fakat bu nadiren gerçekleĢtirilir.
Eğer sayfalar gidilip diskten alınacaksa, bu süre için kilitlenmelidirler. Sayfa
alıp düzenli bir Ģekilde yerleĢtirildiğinde eğer üzerinde normal fiziksel G\Ç yapılıyorsa
kilitlenme ortadan kaldırılmamalıdır.
Sayfa yerleĢtirme algoritması oldukça ilginçtir. VAX'in donanım bellek sayfa
referans biti yoktur. Bu çoğu bellek yönetim algoritmalarını (sayfa hata frekansı gibi)
kullanılmaz yapar. 4.2BSD hafifletilmiĢ bir Global Clock Least Recently Used (LRU)
algoritması kullanır. Tüm çekirdeksiz ana belleğin haritası (core map veya cmap) clock
handler (saat yönetim) yazılımı tarafından doğrusal ve tekrarlamalı olarak taranır.
Clock verilen bir yapıya eriĢtiğinde, eğer yapı bazı yazılım durumları tarafından
kullanımda olarak iĢaretlemiĢse veya yapı zaten serbest ise, ona dokunulmaz ve saat
handler diğer yapıya geçer. Aksi halde, ilgili metin veya iĢlem sayfa tablo giriĢi bu
yapı için yerleĢtirilir. GiriĢ zaten geçersiz ise, yapı serbest eklenir, aksi takdirde sayfa
tablo giriĢi geçersiz fakat geri istenebilir hale getirilir (bir sonraki isteniĢinde dıĢarıya
sayfalanmazsa, tekrar geçerli yapılabilir). KuĢkusuz eğer sayfa dirty ise (VAX 'ın bir
dirty biti vardır), serbest listesine eklenmeden önce diske yazılmalıdır.
Bir iĢlem için gerekli veri sayfasının çok aĢağılara düĢmediğinden emin ve
sayfalama birimlerini ihtiyaçların yağmasından korumak için kontroller vardır.
Programın kullanıldığı belleği kısıtlamayı sağlayan bir mekanizma vardır.
LRU saat yöneticisi, iĢlem 2 olan pagedaemon tarafından implement edilir
(scheduler'in iĢlem 0 ve init'in iĢlem 1 oldugunun hatırlayın). Bu iĢlem, zamanının
çoğunu uyuyarak geçirir, ama hareketin gerekli olup olmadığını anlamak için bir
saniyede birçok kontrol yapılır ve eğer hareket gerekli ise iĢlem 2 uyandırılır. Serbest
yapıların sayısı bir threshold'un altına düĢtüğünde pagedaemon uyandırılır. Çünkü eğer
214
daima birçok boĢ bellek varsa, asla çalıĢmayacağı için pagedaemon sistem üzerinde
hiçbir yükleme yapmaz.
Padegameon iĢleminin uyarıldığı her saat yöneticisi taraması (yani genellikle
sayfalandırılan numaradan daha fazla olan taranılmıĢ yapının numarası), lotofree'ye
eriĢemeyen yapıların sayıları ile ve scheduler 'in belirlediği değiĢik nedenler için
gerekli yapıların sayısı ile belirlenir (Daha çok yapı gerektikçe tarama uzar). Beklenilen
tarama tamamlanmadan, serbest yapıların sayısı lotofree'ye çıkarsa, saat yöneticisi durur
ve pagedaemon iĢlemi uyur. Saat yöneticisi tarama mesafesini belirleyen
parametreler, ana belleğin miktarına bağlı olarak baĢlangıç (startup) sisteminde
belirtilirler. Çünkü pagedaemon CPU' nun %10 'undan fazlasını kullanamaz.
Eğer scheduler sayfalama sisteminin fazla yüklendiğine verirse, fazla yük
bırakılana kadar, iĢlem tamamen dıĢarıya alınır. Bu genellikle birçok durum
birleĢtiğinde olur: Yüksek yük ortalaması, serbest belleğin çok düĢük bir seviyeye
düĢmesi, minfree, ve mevcut bellek ortalamasının istenilen miktarın altında olması,
desfree, (lostfree>desfree>minfree olduğunda). Bir baĢka değiĢle, sadece pekçok iĢlemin
çalıĢmaya uğraĢtığı kronik bellek kıtlığı ve sebest belleğin çok düĢük olması gerektiği
bir anda taramaya sebep olacaktır (Yoğun sayfalama oranı ya da çekirdeğin bellek
ihtiyacı nadir durumlarda hesaplamaya girilebilir). ĠĢlem elbette diğer nedenlerden
dolayı scheduler tarafından değiĢtirilir (uzun süre çalıĢmamak gibi).
Lostfree paramatresi, genellikle clock hand'in taradığı map'teki belleğin dörte
biridir ve desfree ile minfree farklı sistemler üzerinde genellikle aynıdır. Ancak mevcut
belleğin miktarı ile sınırlandırılmıĢlardır.
Her iĢlemin text segmenti default olarak bir paylaĢımlı, sadece okunur text
segment'tir. Bu, sayfalama açasından pratiktir, çünkü harici parçalanma yoktur ve
çekirdek görüntü boĢluğu büyük paylaĢımla kazanılmıĢ değiĢim boĢluğu, fazla yükün
ihmal edilebilir miktarını çok aĢar.
CPU scheduling, değiĢim ve sayfalama birbrini etkiler: ĠĢlemin önceliği
azaldıkça, sayfaların sayfalandırma ve bütünü ile değiĢtirilme ihtimali artar.
DeğiĢtirilecek iĢlemlerin seçimindeki yaĢ tercihi koruma iĢlemi yapar, fakat
sayfalama bunu çok etkin olarak yapar. Ġdeal olarak, her iĢlem herhangi bir anda ana
bellekte sadece sayfaların küçük bir çalıĢan setine gerek duyacağından boĢ olmadıkları
sürece iĢlemler değiĢtirilmeyecektir. Pagedaemon diğer iĢlemler tarafından kullanılması
için kullanılmayan sayfaları geri alacaktır. Bundan dolayı birçok çalıĢabilen iĢlem asla
tamamen dıĢarıya alınmayacaktır (değiĢtirilmeyecektir).
Eğer uzun bir süredir degiĢtiriliyorsa, iĢlemin ihtiyacı olan bellek miktarı, toplam
görüntü büyüklüğünün 1/2'ye kadar çıkabilen oranlarıdır.
G/Ç etkinliği için, VAX'ın 512 byte donanım sayfaları çok küçüktür, bu yüzden
tüm G\Ç sayfalamasının gerçekte 1024byte'lık parçalarda yapıldığı iki gruba ayrılırlar.
215
BaĢka bir deyiĢle etkin (effective) sayfa boyu donanım sayfa boyuna bağlı değildir.
Fakat bunun tam katları olmalıdır.
36.8. GiriĢ-ÇıkıĢ Sistemleri
Bir iĢletim sisteminin amaçlarından biride bazı donanım elemanlarının
garipliklerinden kullanıcıyı uzak tutmaktır. Örneğin, kütük sistemi kullanıcıya,
altındaki kütük donanımından bağımsız, kalıcı bir bellek kullanımı sağlar. Unix
iĢletim sisteminde, G/Ç elemanlarının gariplikleri G/Ç sistemi tarafından kulanıcıdan
uzak tutulmuĢtur. G/Ç sistemi, tarafından bir buffer cache sistemi, genel device sürücü
kodu, ve bazı özel donanım elemanlarının sürücülerinden oluĢur. Sadece bu sonuncusu,
device sürücü, belirli bir elemanın karmaĢık yönlerini bilir.
4.2BSD içinde üç ana çeĢit G/Ç vardır:
1) Blok device'ları
2) Karakter device'ları
3) Socket arayüzü
Blok device'ları, disk ve typelerden oluĢur. Bunların ayırıcı özelliği sabit
bloklar, genellikle 512Kb halinde doğrudan adreslenebilmeleridir. Bir blok device
sürücünün çekirdeğin izler ve silindirlerden izole edilmesi gerekir. Blok device'larıda
blok buffer cache'lerinde tamponlanırlar.
Çekirdeğe Sistem Çağırma Arayüzü
Soket
Cooked
Blok
Raw
Blok
Raw
tty
Arayüzü
Arayüzü
Arayüzü
Kütük
Protokol Sistemi
Network
Arayüzü
Blok Device Sürücü
Cooked tty
Line
Disiplini
Karakter Device Sürücü
Donanım
Þekil-98. 4.2BSD Çekirdek Giriþ/Çýkýþ Yapýsý
Karakter device'ları, terminaller ve satır yazıcılarından oluĢur. Buna ek olarak,
network ara yüzleri hariç, blok buffer cache kullanmayan herĢey bu gruptandır. Bazı
device'lar, örneğin yüksek grafik arayüzleri, kendi veri bufferlarına sahip olabilirler,
veya kullacını veri alanına G/Ç yapabilirler. Bunlar blok buffer cache kullanmadıkları
için, karakter device'ları olarak adlandırılırlar.
216
Terminaller ve benzeri devicelar C-list'leri'ni kullanırlar. Bunlar blok buffer
cache'lerinden daha küçük bufferlardır.
"Blok device" 'ları ve "karakter device" 'ları iki ana device sınıfıdır. Device
drive'larına, giriĢ nokta düzenlerinin ikisinden biri aracılığı ile eriĢilir. Dizinlerin biri
blok device 'ları, diğeri ise karakter device'ları içindir. Device numaraları iki kısımdan
oluĢur. Major device numarası uygun device'lara yapılacak giriĢlerin dizinlerini
adreslemek için kullanılır. Minör device numarası ise device sürücü tarafından bir
mantıksal disk bölümü veya terminal line olarak görülür.
Bir device sürücü, çekirdeğin diğer kısımlarına kendi sınıfı için olan dizinde
kayıtlanmıĢ giriĢ nokları ve genel buffer sistemiyle bağlıdır.
36.8.1. Blok Buffer Cache
Blok device'ları blok buffer cache kullanırlar. Bir buffer cache, herbiri fiziksel
belleğin belli bir kısmını gösteren buffer header'larından oluĢur. Buffer header'ları bir
kaç bağlaçlı listede saklanırlar.
- Kesinlikle yazılmayan bilgi, örneğin bir kütük sisteminin süper-blokları.
- En az kullanım sıklağına göre sıralanmıĢ komutlar.
- Hiçbir bellek veya disk bloklarıyla ilgisi olmayan boĢ bufferlar.
Bu listelerdeki bufferlar ayrıca arama etkinliği için özel olarak sıralanmıĢlardır.
Bir blok device'tan okuma için istendiği zaman, cache içinde aranır. Eğer blok
bulursa, bu kullanılır ve herhangi bir G/Ç yapılmaz. Eğer bulamazsa, boĢ buufer
listesinden bir buffer seçilir ve onunla ilgili device numarası ve blok numarası
günlenir, gerekli bellek ayrılır ve yeni veri transfer edilir. Eğer hiç buffer yoksa, en az
buffer kullanılmak üzere boĢaltılır.
Yazma iĢlemi sırasında ise, eğer söz konusu blok buffer cache içindeyse yeni
buffera konur (eski bilginin üzerine yazılır). Buffer header artık günlenmiĢ bufferı
gösterecek Ģekilde düzenlenir, hemen bir G/Ç iĢlemi gerekmez. Veri, buffer baĢka bir
veri için istendiğinde yazılacaktır. Eğer blok, buffer cache içinde bulunmazsa, boĢ bir
buffer seçilir (okuma iĢleminde olduğu gibi) ve bu buffera transfer yapılır.
Bir bozulmadan sonra kütük sistemindeki kararsızlıkları en aza indirmek için
periyodik yazmalar kötü buffer blokları için desteklenirler.
4.2BSD'nin bir bufferındaki veri miktarı değiĢkendir, genellikle de maksimum
8K'dır. En küçük miktar sayfalama cluster boyu olan 1024 byte'dır. Bufferlar sayfaclusterlarına uyarlanmıĢlar ve bir sayfa clusterı bir anda sadece bir buffera ait
olabilirler. Bir disk bloğunun bir anda sadece buffera ait olabileceği gibi.
217
Bir bufferdaki veri, kullanıcı buffera sürekli veri yazarsa artar. Bu olduğu
zaman, yeni bir buffer açılır, bunun büyklüğü yeni veriyi tutacak kadardır ve orjinal
veri onun içine kopye edilir. Eğer bir bufferdaki yer azalırsa, boĢ buffer kuyruğundan
bir buffer alınır ve o buffer diske yazılmak üzere serbest bırakılır.
Bazı device'lar, örneğin manyetik teypler, blokların belli bir sırada yazılmasını
gerektirirler, bu nedenle bu iĢlemi gerçekleĢtirmek için bazı kolaylıklar sağlanmıĢtır.
Directory'lerin blokları senkranize olrak yazlırlar.
Bir buffer cache boyutu sisteminin performansını çok derinden etkileyebilir,
çünkü bunun etkin olarak kullanılmasıyla, sistemde yapılan G/Ç iĢlemleri oldukça
azaltılabilir.
Buffer cache, kütük sistemi ve disk sürücüleri arasında ilginç bazı iliĢkiler
vardır. Veri bir disk kütüğüne yazıldıgı zaman, cache içinde tamponlanır ve disk
sürücü kendi çıktı kuyruğunu bu disk adresine göre sıralar. Bu ikisi, disk sürücünün
minimum arama zamanında en uygun kafa hareketleri ile iĢlem yapmasını sağlarlar.
Okuma iĢlemleri yazmalara göre daha az senkronize durumdadırlar. Bu nedenle, kütük
sistemi aracılığıyla diske yapılan bir çıktı iĢlemi girdi iĢleminden daha hızlıdır.
36.8.2. Raw Aygıtlarının Arayüzleri
Hemen hemen her blok device aynı zamanda bir karakter ara yüzüne sahiptir.
Bunlara raw device arayüzleri denir. Bu çeĢit bir ara yüz blok ara yüzünden farklıdır.
Her disk sürücü, transferlerini sağlamak için bir kuyruk kullanılır. Kuyruktaki
her kayıt, onun bir okuma mı yazma mı olduğunu, transfer için bellek adresini, transfer
için device adresini ve transfer boyutunu (byte olarak) içerir. Bir blok bufferdan bu
kuyruk için neler gerektiğini anlamak oldukça kolaydır.
36.8.3. C Listeleri
Terminal sürücüleri karekter buffer sistemini kullanırlar. Bu, küçük karekter
bloklarını içerir (genellikle 28 byte). Bu karakterler bağlı listelerde saklanırlar. Bu
karakterleri kuyruklamak ve kuyruktan çıkarmak için çeĢitli yöntemler vardır. Bütün
serbest karakter bufferları tek bir serbest listede tutulması rağmen, onları kullanan
device sürücülerinin çoğu bir anda kullanacakları karakter sayısını sınırlarlar.
Bir yazma isteğinde terminal, karakterleri device için bir listede kuyruklar. Ilk
transfer baĢlatılır ve kesintiler yapılan iĢlemleri kontrol eder.
GiriĢler de aynı Ģekilde kesintilerle düzenlenirler. Terminal sürücüleri
genellikle iki kuyruğunu desteklerler.
36.9. ĠĢlemler Arası ĠletiĢim (INTERPROCESS COMMUNICATION-IPC)
218
Bazı iĢlemler yalın iĢlemler içersinde gercekleĢtirilebilir. Fakat diğer bir çokları
iĢlemler arası iletiĢime gereksinim duyarlar. Yalın iĢlem dizgeleri bir çok uygulamaya
hizmet etmiĢtir. Fakat ağ olgusu (networking) giderek daha fazla önem taĢımaktadır.
KiĢisel iĢ istasyonlarının artan kullanımı ile kaynak bölüĢümü de yaygınlaĢmaktadır.
ĠĢlemler arası iletiĢim geleneksel açıdan Unix'in güçlü yönlerinden biri olarak
süregelmiĢtir.
Unix dizgelerinin çoğunluğu paylaĢımlı belleğe izin vermemiĢtir. Çünkü PDP-11
donanımı buna uygun değildir. Sistem V, paylaĢımlı bellek kulanımına izin verir ve
bunlardan biri 4.2BSD için planlanmıĢtır, fakat zaman sınırlamaları nedeni ile
uygulanmamıĢtır. Yine de zaman paylaĢımlı bellek, iletiĢim ağı (network) kullanılan
çevrelerde sorun yaratmaktadır. Çünkü ağ eriĢimleri hiç bir zaman makinanın belleğine
eriĢim kadar hızlı olamazlar.
Verileri iletiĢim ağına görünmez bir biçimde kopya ederek bir belleğin iki ayrı
makina tarafından kullanımı önlense bile paylaĢımlı belleğin en önemli özelliği olan
hızdan kayıp söz konusu olacaktır.
36.9.1. Soketler
Unix'in en önemli karekteristiğini pipe mekanizması taĢır. Bir pipe, iki iĢlem
arasında güvenilir bir tek-yönlü bayt akıĢına izin verir. Bu mekanizma bir kaç istisna
dıĢında sıradan bir kütük gibi oluĢturulmuĢtur. Kütük dizgesi içinde ismi yoktur; bunun
yerine pipe sistem çağrısı ile yaratılır. Boyu sabittir; bir iĢlem, dolu bir pipe'a yazma
giriĢiminde bulunursa o iĢlem durdurulur. Pipe içersinde önceden yazılmıĢ olan tüm veri
bir kez okunduğunda yazma iĢlemi küçük boyutlarının (4096 bayt) bir faydası, pipe
verilerinin gerçekte nadiren diske yazılması; bunun yanında genellikle normal blok
tampon bölgesi kullanılarak bellekte saklanmasıdır.
4.2BSD'de pipe'lar soket (socket) mekanizmasının özel bir durumu olarak
gerçekleĢtirilir. 4.2BSD soket mekanizması yalnız bir makinada yerel olarak bulunan
pipelara değil, ayrıca ağ tesisatlarına da genel bir arayüz sağlar.
Bir soket, iletiĢimin bitiĢ noktasıdır. Kullanımda olan bir soket genellikle
kendisine bağlı bir adrese sahiptir. Adresin yapısı soketin iletiĢim sahasına bağlıdır. Bir
sahanın karakteristik özelliği, aynı adres formatını kullanmasıdır. Tek bir soket yalnızca
bir saha içersinde iletiĢim yapabilir.
4.2BSD içersinde Ģu ana kadar gerçekleĢtirilmiĢ sahalar Unix sahası(AF Unix)
ve Internet sahasıdır (AF INET). Unix sahasının adres formatı her zaman kullanılan
kütük sistemi yol isimlerinden (pathname) oluĢur: /alpha/beta/gama gibi. Internet
sahasında iletiĢim yapan iĢlemler DARPA Internet iletiĢim protokolleini (TCP/IP gibi)
ve 32-bit port numarasından oluĢan Internet adreslerini kullanırlar.
Bir çok soket tipi vardır; bunlar servis sınıflarını belirler. Her tip, herhangi bir
iletiĢim sahasında bulunabilir veya bulunmayabilir. Eğer, bir tip belli bir saha içersinde
219
bulunuyorsa, bir veya daha fazla protokol tarafından tanımlanabilir; seçim kullanıcıya
aittir.
- Akım (stream) soketleri güvenilir, duplex, sıralı veri akıĢı sağlar.
Verinin kaybolması yada ikilenmesi (duplikasyon) söz konusu değildir ve herhangi bir
kayıt sınırlaması yoktur. Bu tip, Internet sahasında pipelar, çiftler halinde iletiĢim yapan
akım soketleri olarak düzenlenmiĢlerdir.
- Sıralı paket (sequenced packet) soketleri, akım soketlerine benzer bir
veri akıĢı sağlar fakat bunlarda veri sınırlaması vardır. Bu tip halen desteklenmektedir
ama Xerox XNS protokolu ile benzeĢmektedir.
- Datagram soketleri değiĢken boyutlardaki mesajları her iki yönde de
iletebilmektir. Mesajların gönderildiği sırada ulaĢacağına, duplike edilmeyeceğine ve
hatta bütün olarak ulaĢacağına iliĢkin bir garanti yoktur. Fakat yerine ulaĢan orjinal
mesaj(kayıt) boyutu her datagramda korunur. Bu tip, Internet sahasında UDP protokolu
tarafından da desteklenir.
- EriĢim güvenceli mesaj (reliably delivered message) soketleri yerine
ulaĢması garanti edilebilecek mesajları transfer eder; aksi halde datagram soketlerine
benzer bir nitelik taĢır. Bu tip halen desteklenmemektedir.
- Ham (raw) soketler, iĢlemlerden, baĢka soket tiplerini destekleyen
protokollere doğrudan eriĢime izin verir. EriĢilebilen protokoller sadece en üst
düzeydekileri değil, düĢük düzeydeki protokolleride içerir. Örneğin Internet sahasında
TCP'ye, onun altında IP'ye, veya onun da altında yeni protokol geliĢtirmek için
yararlıdır.
Soket dizgesi, kendine özgü sistem çağrılarına sahiptir. 'Socket' sistem çağrısı
yeni bir soket yaratır. ĠletiĢim sahası, soket tipi, o tipi destekleyen protokolleri kapsayan
arguman özelliklerini içerir. Geri dönen değer, kütük tanımlayıcıları ile aynı isim
bölgesinde bulunan ve soket tanımlayıcısı olarak isimlendirilen küçük bir tam sayıdır.
Soketi adresleyecek baĢka bir iĢlem için soketin bir ismi olmalıdır. Ġsim, sokete
bind (bağlayıcı) sistem çağrısı ile bağlıdır ve soket tanımlayıcısı, isim iĢaretleyici
(name pointer) ve isim uzunluğunu bir byte katarı içinde tutar. Byte katarının içerikleri
ve uzunluğunu adres formatına bağlıdır.
IPC soketini kullanarak iletiĢim yapan bir çok iĢlem, 'alıcı/hizmet verici'
(client/server) modelini izler. Bu modelde hizmet veren iĢlem, alıcı iĢleme bir servis
sağlar. Hizmet verici iĢlem servise hazır olduğunda belli bir adresi denetler ve alıcı
iĢlem servise ulaĢmak için bu bağlantıyı kullanır.
Hizmet veren iĢlem, soket yaratmak üzere socket, kullanılan adresi bağlamak
üzere de bind çağrılarını kullanır. Daha sonra, alıcıya bağlanmaya hazır olduğunu
belirtmek için listen dizge çağrısı kullanılır. Son olarak, her bağlantıyı teker teker kabul
etmak için accept sistem çağrısı kullanılır. accept, yeni bağlantıya uyan yeni bir soket
tanımlayıcısı oluĢturur.
220
Akım soketi gibi bir soket tipi için bir bağlantı oluĢturulduğunda her iki bitim
noktasının adresi bilinmektedir ve veri transferi için baĢka bir adresleme bilgisine
ihtiyaç yoktur. Bildiğimiz read ve write sistem çağrıları, daha sonra veri transferi içinde
kullanılabilir.
Bir bağlantıyı kesmek veya kurulmuĢ soketi ortadan kaldırmak için en basit yol,
ilgili soket tanımlayıcısı üzerinde close sistem çağrısını kullanmaktır. Bir duplex
bağlantıyı tek yönlü kapatmak için de shutdown sistem çağrısı kullanılabilir.
Datagram gibi bazı soket tipleri bağlantılara izin vermez; onun yerine bunların
soketleri, ayrık olarak adreslanmesi gereken datagram'ları değiĢtirir. sendto ve
recvfrom sistem çağrıları bu bağlantılar içindir. Her ikiside argüman olarak soket
tanımlayıcısı, tampon iĢaretleyici, tampon uzunluğu ile adres tampon bölge iĢaretleyicisi
ve uzunluğunu kullanır. Adres tamponu sendto için gönderi adresini içerir ve recvfrom
ile elde edilen datagramın adresi ile doldurur. Gerçekte transfer edilen veri miktarı her
iki sistem çağrısı ile sağlanır. select sistem çağrısı çeĢitli kütük tanımlayıcıları üzerinde
veri transferi çoklaması (multiplex) amacı ile kullanılabilir.
36.9.2. Network (Ağ) Desteği
Hemen hemen tüm Unix sistemleri, UUCP posta ağı ve USENET haberleĢme
ağını desteklemek üzere telefon hatları üzerinde kullanılan UUCP ağ tesisatlarını
destekler. Fakat bunlar, uzaktan açma kontroluna bile izin vermeyen en temel ağ
tesisatlarıdır.
4.2BSD, DARPA Internet protokolleri olan UDP, TCP, IP ve ICMP
protokollerini Ethernet, token ring ve Arpanet arayüzleri üzerinde destekler. Bunu
gerçekleĢtiren tasarımlar, daha ileri protokollerin yürütülmesine izin verir ve bunların
tümü bir soket arayüzü ile eriĢilebilir.
Uluslararası Standart Organizasyonu(ISO)'nun ağlar için Açık Sistem
Arabağlantısı (OSI) baĢvuru modeli 7 katmanlı network protokolleri ve bunların
arasında kullanılacak iletiĢim metodlarını harfi harfine tanımlayarak düzene koymuĢtur.
Bir protokolun yürütülmesi sırasında, yalnızca aynı protokolun aynı katmanındaki bir
birim ile, ya da bir protokolun aynı sistem içersinde bir alt veya bir üst katman ile olan
protokol-protokol arayüzü ile iletiĢim kurulabilir.
4.2BSD ağının tasarımı daha çok Arpanet Reference Model(ARM)'e yöneliktir.
Paket anahtarlama ve protokol katmanlama gibi birçok ağ kavramları için Arpanet,
orjinal bir kavram ispatı olarak hizmet etmiĢtir. DARPA, Internet içersindeki kardeĢ
ağlarıyle beraber, Internet geçiĢ araĢtırmaları için bir test materyalidir. ARM, ISO
modelinden daha önce gelistirilmiĢtir ve bu ikincisi büyük ölçüde Arpanet
araĢtırmalarından ilham almıĢtır.
ISO modeli genellikle her katman(layer) için tek bir protokol iletiĢimi limitine
ihtiyaç duyması ile yorumlanırken ARM, aynı katman içersinde bir çok protokole izin
221
verir. ARM, aynı katman içinde birçok protokole izin verir. ARM içersinde sadece uç
protokol katmanı bulunur:
- IĢlem/Uygulamalar (Process/Applications), ISO modelinin uygulama
(application), sunma (presentation) ve oturum (session) katmanlarından oluĢur. Kütük
transfer protokolü (FTP) ve Telnet (uzaktan açma) gibi kullanıcı düzeyindeki
programlarda bu gruptadır.
- Evsahibi-evsahibi (host-host), ISO'nun nakil ile ağ katmanlarının en üst
kısmı ile benzeĢir. Hem Ġletim Denetleme Protokolu (Transmit Control Protokol-TCP)
hem de Internet Protokolu (IP) bu katmanda TCP/IP'nin üstünde olmak kaydıyla
bulunurlar. TCP, bir ISO iletim protokolune benzer ve IP, ISO ağ katmanının adresleme
fonksiyonlarını gerçekleĢtirir.
- Ağ donanımı (network interface), ARM temel olarak yazılım ile
ilgilenir, bu nedenle fazladan bir ağ donanım katmanı yoktur; fakat herhangi bir ağ, ISO
donanım katmanına benzer bir donanıma sahip olmalıdır.
4.2BSD içindeki ağleĢme çerçevesi ISO modelinden veya ARM'dan daha
genelleĢtirilmiĢtir. Yine de ARM ile çok yakından bağlantılıdır. AĢağıdaki tabloya
bakınız.
ISO Baþvuru
Modeli
ARPANET
Başvuru Modeli
Aplication
Process /
Presentation
Applications
Session
Transport
Network
Data link
Hardware
4.2BSD
Katmanları
Örnek
Katmanlama
Kullanıcı
programları &
Kütüphaneler
Soketler
SOCK-STREAM
TCP
Host-host
Protokoller
Network
Interface
Network
Interfaces
Ethernet Driver
Network
Hardware
Network
Hardware
Interlan Control.
IP
Kullanıcı iĢlemleri ağ protokolleri ile, ISO oturum katmanına benzeyen soket
üzerinden iletiĢim kurar. Soketler protokoller tarafından desteklenirler, muhtemelen bu
destek değiĢik protokollerin birer katman oluĢturmasıyla gerçekleĢir. Bir protokol;
güvenceli iletim, duplike iletilerin önlenmesi, akıĢ kontrolü veya adresleme gibi
hizmetler sağlayabilir. Bu hizmetler kullanılan soket tipi ile daha yüksek protokollerin
ihtiyaç duyduğu servislere göre değiĢir.
Bir protokol, bir baĢka protokol veya ağ donanımına uygun bir ağ arayüzü ile
iletiĢim kurabilir. Bir protokolun hangi protokollerle iletiĢim kurabileceği veya kaç
222
protokolun birbiri üzerinde katmanlanacağı konularında gerçekte çok az kısıtlama
vardır. Kullanıcı iĢlemi, ham soket üzerinden protokolun herhangi bir katmanına
doğrudan eriĢebilir. Bu özellik yönlendirici iĢlemler tarafından ve ayrıca yeni bir
protokol tasarımı için kullanılabilir.
Her ağ denetleyicisi için bir ağ arayüzü hazır bulunur. Ağ arayüzü,
adreslenmekte olan yerel ağının karakteristiklerini, protokollerin onlarla ilgilenmesine
gerek bırakmadan yürütmekle sorumludur.
Ağ arayüzünün fonksiyonları önemli ölçüde ağ donanımına bağlıdır. Bazı ağlar
bu düzeyde güvenilir iletim sağlayabilir. Fakat çoğu bunu sağlamaz. Bazıları yayın
(broadcast) adreslemeyi desteklerken çoğu buna izin vermez.
ÇeĢitli organizasyonlar tarafından -DARPA Internet haricinde- bir çok protokol
projeleri tasarlanmaktadır. Bunların arasında ISO'nun, OSI modeline uydurmak üzere
benimsediği protokoller de bulunmaktadır.
Soket kolaylığı ve ağ çerçevesi, kısaca mbuf olarak isimlendirilen bir küme
tampon sahası kullanır. Bunlar, blok giriĢ/çıkıĢ sisteminin kullandığı büyük tamponlar
ile karakter araçlarının kullandığı C-listeleri arasında bir büyüklüğe sahiptir. Bir mbuf,
112 baytının veri için kullanılabileceği 128 bayttan oluĢur. Geri kalanlar mbuf'ı
kuyruklara bağlamak amacıyla kullanılan iĢaretleyiciler için ve veri sahasının gerçekte
ne kadarının kullanımda olduğunu göstermek amacıyla kullanılır.
Veri, mbuf içersinde normal olarak katmanlar arasında gidip gelir
(soket/protokol, protokol/protokol veya protokol/ağ arayüzü). Veri içeren tampon
sahaları geçirebilme olanağı, bazı veri kopyalamalarının önüne geçer, fakat yine de
protokol baĢlıklarını kaldırmaya ve eklemeye gereksinim vardır. Veriyi, bellek yürütme
sayfası büyüklüğünde tutulabilmesi de mümkündür. Bu amaca hizmet vermeye yönelik
mbuf için ayrılmıĢ sayfa kümelerinin yanında bir mbuf sayfa tablosu da bulunmaktadır.
223