işletim sistemleri
Transkript
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