Boru hattı (programlama)

Boru hattı (pipeline), yazılım mühendisliğinde, her bir elemanın çıktısı bir sonraki elemanın girdisi olacak şekilde sıralanmış işlemler zinciridir. Genellikle, ardışık birimlerin aralarına bir miktar arabellek (buffer) konulmaktadır. Bu boruhatları arasındaki bilgi akışı çoğunlukla bayt katarları (stream) ve bit katarları şeklindedir.

Çoklu İşlem Yürütümlü (Multiprocessed) Boruhatları

Boruhatları, en verimli şekilde; tüm komut dizileri aynı anda başlatılarak ve her bir komut dizisi tarafından gönderilen veri okuma isteğine otomatik olarak cevap verilerek, çoklu görev yürütümlü (multitasking) bir işletim sistemine yerleştirilebilirler. Bu şekilde, merkezi işlem birimi (CPU), bekleme süresini en aza indirmek için, doğal bir şekilde, çizelgeleyici (scheduler) tarafından komut dizileri arasında anahtarlanacaktır.

Genellikle, okuma ve yazma istekleri, işlemleri engellemektedir. Bu, yazma üzerinde yürütülen kaynak komut dizisinin, tüm veriler hedef komut dizisine yazılana kadar ertelenmesi ve aynı şekilde okuma üzerinde yürütülen hedef komut dizisinin, en azından istenen verilerin bazıları kaynak komut dizisinden alınana kadar ertelenmesi anlamına gelmektedir. Belli ki bu, her iki komut dizisinin de cevap vermek için birbirlerini belirsiz bir süre bekleyeceği bir kilitlenmeye (deadlock) neden olamaz; çünkü, en azından iki komut dizisinden birinin isteğine en kısa zamanda işletim sistemi tarafından hizmet verilecektir ve komut dizisi yürütülmeye devam edecektir.

Performans için birçok işletim sistemi, kaynak komut dizisinin, hedef komut dizisinin alabileceği veya almak isteyeceği veriden daha fazlasını sağlamasına olanak tanıyan iletişim tüneli arabellekleri (pipe buffer) içermektedir. Çoğu Unice ve Unix benzeri işletim sistemlerinde, genel olarak “arabellek” diye adlandırılan, potansiyel olarak daha büyük ve ayarlanabilir boyutta bir iletişim tüneli arabelleği sağlayan çok özel bir komut da ayrıca mevcuttur.

Bu komut, eğer hedef komut dizisi kaynak komut dizisinden belirgin derecede daha yavaş ise kullanışlı olabilir; ancak yine de kaynak komut dizisinin, mümkün olan en kısa sürede görevini tamamlaması arzulanmaktadır. Örneğin, kaynak komut dizisi, CD’den ses kaydı okuyan bir komuttan oluşuyor olsun ve hedef komut dizisi, dalga biçimindeki ses verisini OGG Vorbis formatında sıkıştıran bir komuttan oluşuyor olsun. Bu durumda, ses kaydının tamamını iletişim tüneli arabelleği içinde saklamak, CD sürücüsünün daha hızlı durmasına ve kullanıcının şifreleme (encode) işlemi tamamlanmadan CD’yi sürücüden çıkarabilmesine olanak tanıyacaktır.

Bu tür bir arabellek komutu, mevcut işletim sistemindeki veri okuma ve yazma temel öğeleri ile gerçekleştirilebilir. Zaman kaybettiren aktif bekleme (active waiting), poll, select veya multithreading gibi avantajlar kullanılarak önlenebilir.

VM/CMS ve MVS

CMS boruhattı, bizi VM/CMS ve MVS sistemlere götüren boruhattı fikrinin giriş aşamasıdır. Bu, çoklu girdi katarlarını alıp bunlardan çoklu çıktı katarları üreterek, Unix kabuklarından (shell) çok daha karmaşık boruhattı yapılarını destekler. [Böyle bir işlevsellik Unix çekirdeği (kernel) tarafından desteklenmektedir, ancak çok az program bunu kullanır ve hiçbir kabuk bunun için bir sözdizim (syntax) sağlamaz.] IBM mainframe işletim sistemleri, farklı doğaları yüzünden, CMS boruhatları içine, Unix’te farklı harici programlar şeklinde olan birçok adım eklemişlerdir; fakat aynı zamanda, işlevsel olmaları için, farklı harici programları çağırabilirler. Aynı zamanda, IBM mainframe dosyalarının kayıt bazlı (record-oriented) doğaları nedeniyle, boruhatları, akış bazlı (stream-oriented) değil de kayıt bazlı düzende çalışırlar.

Sözde Boruhatları (Pseudo-Pipeline)

Tekli görev yürütümlü (single-tasking) işletim sistemlerinde boruhattının komut dizileri teker teker, sıralı düzende yürütülmek zorundadır; öyle ki, her bir komut dizisinin çıktısı, bir sonraki komut dizisi tarafından okunmak üzere, geçici bir dosyaya kaydedilmelidir. Paralellik ve CPU anahtarlama olmadığından bu türe “sözde boruhattı” denir.

Örnek olarak, MS-DOS komut güdüsü (command prompt) yorumlayıcısı (COMMAND.COM), Unix boruhatlarının sözdizimine benzer, yüzeysel bir sözdizim sağlamaktadır. “dir | sort | more” komutu şu şekilde yürütülecektir (tabii ki daha karmaşık geçici dosya adları kullanılarak):

1. 1.tmp adlı geçici dosyayı yarat
2. “dir” komutunu, çıktısını 1.tmp dosyasına yönlendirerek, çalıştır
3. 2.tmp adlı geçici dosyayı yarat
4. “sort” komutunu, girdisini 1.tmp dosyasına ve çıktısını da 2.tmp dosyasına yönlendirerek, çalıştır
5. “more” komutunu, girdisini 2.tmp dosyasına yönlendirerek ve çıktısını kullanıcıya sunarak, çalıştır
6. Daha fazla ihtiyaç kalmadığından, 1.tmp ve 2.tmp dosyalarını sil
7. Komut güdüsüne geri dön

Tüm geçici dosyalar %TEMP% ile işaret edilen bir klasörde (eğer %TEMP% ayarlanmamışsa, içinde bulunulan klasörde) saklanır.

Böylece, gönderme komut dizisi (sending process) tamamlanmadan alma komut dizisinin iletişim tüneli arabelleğinden veri okuması kesinlikle engellenmiş olmakla birlikte, sözde boruhatları sınırsız boyutta iletişim tüneli arabelleğine sahip (disk alanı sınırlamaları dikkate alınmadan) gerçek boruhatları gibi davranırlar. Disk trafiğine neden olmanın ötesinde; eğer SMARTDRV gibi bir sabitdisk önbelleği (önbellek) kurulmazsa, ki bu çoklu görev yürütümlü işletim sistemleri için gerekli değildir; bu gerçekleştirim (sözde boruhattı) aynı zamanda boruhatlarını gerçek zamanlı tepkiler gerektiren uygulamalar için; örneğin, etkileşimli amaçlar gibi (kullanıcı, boruhattındaki ilk işlemin stdin aracılığıyla aldığı bir komut dizisi girer ve boruhattındaki son komut dizisi, çıktısını stdout aracılığıyla kullanıcıya sunar), uyumsuz hale getirdi.

Aynı zamanda, yes komutu gibi potansiyel olarak sonsuz miktarda çıktı üreten komutlar, sözde botuhattı içinde kullanılamazlar. Öyle ki, bu komutlar geçici disk alanı tükenen kadar çalışacaklardır, böylece botuhattı içindeki takip eden işlemler çalıştırılamayacaktır.

GUI’ler İçinde Boruhatları

RISC OS ve ROX Desktop gibi grafiksel ortamlar da botuhatları kullanırlar. Kullanıcının, bir programın nereye veri yazacağını belirtmesini sağlayan, dosya yöneticisi içeren bir kayıt diyalog kutusu sunmak yerine; RISC OS ve ROX, bir simge (ve ismi belirtmek için bir alan) içeren kayıt diyalog kutusu sunmaktadırlar. Hedef, simgenin sürüklenip bırakılmasıyla belirlenir. Kullanıcı, diğer programların simgeleri de dahil, kaydedilmiş bir dosyanın bırakılabileceği her yere simgeyi bırakabilir. Eğer simge bir program simgesinin üzerine bırakılırsa, program çalıştırılır ve normalde kaydedilmesi gereken dosya içeriği, yeni programın standart girdisine verilir.

Örnek olarak, internette gezinen bir kullanıcı, düzenleyip yeniden karşıya yüklemek (upload) İsteyeceği, .gz uzantılı, sıkıştırılmış resim dosyası ile karşılacaktır. GUI boruhatlarını kullanarak kullanıcı, bağı (link) arşiv açma programına sürükleyebilir, açılmış içeriği temsil eden simgeyi resim düzenleyicisine sürükleyebilir, farklı kaydet diyalogunu açabilir ve dosya simgesini karşıya yükleme programına sürükleyebilir.

Bu yöntem, geleneksel kayıt diyalog kutusu ile de kullanılabilir; ancak bunun için, kullanıcının programlarının dosya sisteminde açık ve kolay erişilebilir konumlara sahip olmaları gerekmektedir. Uygulamada bunun yerine sıklıkla GUI boruhatları kullanılır.

Diğer konular

• Bir boruhattı, bilginin, borularda akan su gibi sadece tek yönde akmasına izin verir. Bunun haricinde, genel olarak, su bir boruda iki yönde de akabilir.
• Boruhatları, işlevsel programlamanın, byte katarlarını veri nesnesi olarak kullanan bir biçimi olarak görülebilir.
• Boruhattı kavramı, kaynak veri katarının görüntülenmeden önce değiştirilebileceği, Cocoon web geliştirme çatısının (framework) merkezindedir.
• Boruhattı kavramı, TextPipe gibi veri madenciliği araçlarında da kullanılır.