Previous
Next

JAVA - Çok kanallı (Multi-Threaded) programlama

by Cem Kefeli 16. Haziran 2014 00:00

Tüm java makalelerime buradan ulaşabilirsiniz...Java

Yazdığım 15 kadar Java makalesinden sonra düşündüm ki Java'da çok kanallı programlamadan bahsetmemek büyük bir eksiklik olmuş bu yazı dizisi için. Şu sıralar üzerinde uğraştığım bir proje de bu durumu biraz tetikledi açıkçası. Hazır çok kanallı programlamaya (ki bundan sonra multi-threading diyeceğim...) derinlemesine inmişken bu konuya da yüzelsel olarak bir değinmek istedim.

Programlama dillerini iş yapan bir işçiye benzetirsek, tıpkı bir işçi gibi işlerini belirli bir sırayla yaptığını görürürüz. Yani bir program parçacığı çalışır, bir işi yapar, bititir, sonra bir diğer işe başlar, onu bititir, sonra bir yenisine başlar. Süreç bu şekilde kendisine verilen işler bitene kadar devam eder. Eğer yalnızca bir işçiniz varsa burada işçi için değil de iş süreci için bir çıkmaz oluşacağını hissetmişsinizdir. Tabi ki burada işin niteliği de önemlidir. Çünkü bir işçi yalnızca ve yalnızca kendisine verilen bir işi yerine getirir, işi bitmeden de bir diğer işi yapamaz. Peki ya bizim senkron bir şekilde yapılması gereken işlerimiz varsa ne olacak? Cevap basit aslında yeni işçiler almalıyız. İşte programlamada çoklu-işçiliği sağlayan multi-threaded yapılardır. Bu arada "Ne kadar senkron?" sorusunu aklınızın bir kenarına şimdilik not edin, ilerleyen dakikalarda inceleyeceğiz...

Programlama hayatından daha gerçekçi bir örnek vererek ilerleyelim;

Örneğin bir uygulama yazmak istiyoruz. Bu uygulama hem sürekli ekrana birşeyler yazacak hem de bir yandan ben klavyeden hangi metni girersem onu alıp aynen ekrana basacak. Yani iki iş parçacığından oluşuyor. Eğer multi-threaded bir yapı kullanmazsanız böyle bir uygulamayı gerçek anlamda oluşturamazsınız. Yapılacak işler birbiri ile çakışır, senkron değil de birbirini beklemek zorunda kalan iş parçacıkları oluşur.

Multi-Threaded Example-1  |  Gizle  |  Göster
package multithreaded.sample1;

/**
 *
 * @author Cem Kefeli
 */
public class MultiThreadedEx1 {
    public static void main(String[] args) {
        Thread_Read threadRead=new Thread_Read();
        Thread_Write threadWrite=new Thread_Write();
        threadRead.start();
        threadWrite.start();
    }
}
package multithreaded.sample1;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

/**
 *
 * @author Cem Kefeli
 */
public class Thread_Read extends Thread {
    @Override
    public void run() {
        BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(System.in));
        String text="";
        
        while(true) {
            try {
                text = bufferedReader.readLine();
            } 
            catch (IOException Exc) {
                System.out.println(Exc);
            }
            System.out.println("Echo: "+text);
        }
    }
}
package multithreaded.sample1;

/**
 *
 * @author Cem Kefeli
 */
public class Thread_Write extends Thread {
    String text = "Thread example-1";
    
    @Override
    public void run() {
        while(true) {
            try {
                System.out.println(text);
                Thread.sleep(5000);
            } 
            catch (InterruptedException Exc) {
                System.out.println(Exc);
            }
        }
    }
}

Thread example-1
test
Echo: test
Thread example-1
deneme
Echo: deneme
Thread example-1
Thread example-1

Yukarıdaki örnek çok basit bir örnek, fakat görülüyor ki farklı işleri aynı anda yapabiliyoruz artık. Bu mantıkla yalnızca iki adet değil onlarca işi senkron bir şekilde yürütebiliriz. Bir işe başlamak için bir diğer işin bitmesini beklemek zorunda da değiliz böylece.

Yazının başında "Ne kadar senkron?" sorusunu park etmiştik hatırlarsanız, şimdi oraya geri dönelim. Elinizde 1 işçinin 3 saatte bitirebileceği bir iş ve 1 işçinin 5 saatte bitirebileceği ikinci bir iş var. Soru şu; eğer multi-threaded bir yapı kullanırsanız bu iki iş ne kadar zamanda biter, kullanmazsanız ne kadar zamanda biter? Bu arada yeri gelmişken de söylemek lazım Java'da her uygulama en az bir thread'den oluşur ki onun adı da main thread'dir. Yani thread'siz uygulama diye birşey yoktur, "single-thread" ve "multi-thread" kavramları vardır.

İkinci sorunun cevabı daha kolay. Bu iki işin toplam süresi yaklaşık 8 saat sürer diyebiliriz. Yani (toplam süre~=8 saat) denkliği bize gereken cevabı verir.

Ama birinci sorunun cevabı o kadar net değil. Şöyle düşünebiliriz; Bu işler eş zamanlı yapıldığına göre ikisine aynı anda başlasak ilki 3 saat sonra biter, birinci işçi boşa çıkar. İkinci iş ise 5 saatte biter ikinci işçi boşa çıkar. Toplamda da yaklaşık 5 saatte her iki iş de bitmiş olur. Bu söylem göreceli olarak doğru bir mantığa dayanıyor fakat programlama dünyasında eğer her işi bir CPU çekirdeğine yaptırabiliyorsanız geçerli. Eğer bizim tüm işlerimizi aynı CPU çekirdeği yapıyorsa geçersiz. Çünkü ortada toplam belirli miktarda iş var ve bu iş için harcanacak enerji var. Olmayan bir enerjiyi işe dönüştüremeyiz. Dolayısıyla ilk sorunun cevabı (5 saat<toplam süre<8 saat) şeklinde karşımıza çıkar. Örneğin 6 saat olabilir ama asla ve asla 5 saat olamayacaktır. Örneğin 5 saat 1 saniye olabilir ama asla ve asla 5 saat olmayacaktır!

Threadless vs. Multi ThreadingBu durumu daha net ortaya koyabilmek için yüklü matematiksel hesaplamalar yapan bir method (iş) yazdım. Bu işten CPU'ya 1 den başlayarak 50 defaya kadar yaptırdım, her bir iş sayısı için toplam işin ne kadar sürdüğünü hesaplattım. Grafikteki yatay eksen işten kaç defa yapıldığını adet cinsinden gösteriyor. Kırmızı bölüm multi-threaded yapı olmadan, yani aslında single-threaded, toplam işin 1 ile 50 arasında değişen sayısı için milisaniye cinsinden ne kadar sürdüğünü gösteriyor. Burada bizi şaşırtan bir durum yok. İşler peşpeşe yapılıyor ve bir iş yaklaşık 1,450 milisaniye (ms) sürüyor 50 defa yapılması da yaklaşık 72,750 ms sürüyor. Beklenen değer ve gerçekleşen değerler neredeyse birbirinin aynısı. Grafikten de görüleceği gibi kızmızı taralı alan çok belirgin ortaya çıkmıyor.

Fakat multi-threaded yapıda, yani mavi alan, yukarıda bahsettiğim sonuç çok net ortaya çıkıyor. normalde 50 işin aynı anda başlayıp eş zamanlı yapılması sonrasında 50 işin de 1450 ms sonra bitmesi beklenir. Fakat öyle olmuyor, 50 iş senkron bir şekilde toplam 28,500 ms'de bitiyor. Yani aslında her bir iş 28,500 ms saniye sürüyor ve her iş de aynı zamanda bitiyor. İşleri senkron yaptırmamız birim işin süresini uzatıyor. Çünkü her işi bir CPU çekildeğine yaptırmıyoruz, tek bir CPU çekirdeğiyle 50 işi aynı anda yapmaya çalışıyoruz. Grafikten de görüleceği gibi mavi taralı alan çok belirgin bir şekilde ortaya çıkıyor. Peki neden değer arada bir yerde kalıyor? Yani neden single-thread'den yine de az bir süre alıyor işlerin bitmesi. Çünkü multi-threaded yapı kullanarak CPU'nun idle-time değerini azaltıyoruz. Yani CPU'yu daha fazla yüklüyoruz.

Çok çekirdekli CPU'lar biliyorsunuz uzun zamandır kullanımda. Fakat eğer sizin uygulamanız çok çekirdekli bir mimariye uygun bir ortamda çalışmıyorsa çekirdeklerinizin sayısının bir anlamı yok demektir! Buraya çok fazla girmiyorum ama şunu bilmek gerekir ki ve bir başka söylemle çok çekirdekli bir işlemci ancak çok çekirdek üzerinde çalışmaya uygun bir yazılım ortamı ile anlam bulabilir.

Sonuç olarak; bu yazıda işin mantığını anlatmaya çalıştım, bir sonraki yazımda ise multi-threaed yapıların biraz daha detayına inmeyi bekliyorum. Faydalı olması dileğiyle...

Tüm java makalelerime buradan ulaşabilirsiniz...

Weblogic application retirement

by Cem Kefeli 24. Mayıs 2014 21:47

SOAP vs. RESTFULBir uygulamanın ilk deployment sonrasında öylece bırakıldığı ve yaşamı süresince bir daha hiç güncellenmediği neredeyse hiç karşılaşılmayan bir durum. Uygulamalar da insan ihtiyaçlarıyla birlikte yaşayan ve bir ömürleri olan yapılar. Günün koşullarına göre ihtiyaçları karşılayabiliyorken bir süre sonra oluşan yeni iş ihtiyaçları doğrultusunda yeni geliştirmeler yapmak gerekebiliyor. Yapılan bu yeni geliştirmeler sonrasında da tabiki güncel uygulamaların tekrar deploy edilmesi gerekli oluyor.

Weblogic uygulama sunucusu bir uygulamanın silinip tekrar yüklenmesi ile aynı uygulamanın re-deploy ya da update edilmesini farklı şekillerde ele alıyor. Daha doğrusu bir uygulama update ediliyorsa iş anlamında da gerçekten yeni gelen bir özelliğin aktif edileceği konseptine bağlı kalmaya çalışıyor. Aslında pratik yaşamda bir uygulamanın silinmesi sonrasında yenisinin tekrar yüklenmesi ile uygulamanın update edilmesi arasında bir fark yok. Nihayetinde ikisinde de yeni uygulama hayatına başlamış oluyor. Ama asıl fark update özelliğinin sunmuş olduğu yenenekler kullanılırsa ortaya çıkıyor.

Weblogic, uygulama paketleri içerisinde yer alan manifest dosyaları sayesinde uygulama versiyonunu takip edebilme ve değişikliği anlayabilme yetisine sahip. Eğer aşağıdaki gibi bir manifest dosyasını uygulama içerisine olması gereken yere eklerseniz daha ilk deployment aşamasında uygulama versiyonlanmış olacaktır.

MANIFEST.MF (applicationRetirement - Version Blue - v1.0.0)  |  Gizle  |  Göster
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.9.4
Created-By: Cem Kefeli (cemkefeli.com)
Weblogic-Application-Version: 1.0.0
Build-Timestamp: 2014-05-24 10:12:15 598

Eğer aşağıdaki gibi bir sonraki güncel uygulamada (Yani bu örnek için 'Version Red - v2.0.0') versiyon bilgisi değişirse, Weblogic bu durumdan da haberdar olacak ve hem mevcuttaki uygulamanın hem de güncel uygulamanın admin kontrolünde birlikte yaşamasına imkan tanıyacaktır.

MANIFEST.MF (applicationRetirement - Version Red - v2.0.0)  |  Gizle  |  Göster
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.9.4
Created-By: Cem Kefeli (cemkefeli.com)
Weblogic-Application-Version: 2.0.0
Build-Timestamp: 2014-05-24 10:17:15 598

Aşağıdaki adımlar takip edilerek Weblogic uygulama sunucusunda nasıl versiyonlama ve update yapılabileceğini görebilirsiniz. Versiyonlanmış iki örnek uygulamayı da yazının bitimindeki linkleri kullanarak indirebilirsiniz;

Weblogic - Application RetirementFazlası...

Samsung Note 2 Android 4.4.2 güncellemesi

by Cem Kefeli 23. Mayıs 2014 01:16

Android Kitkat 4.4Yaklaşık birkaç ay önce Samsung Note 2 cihazımın OS seviyesini 4.3'e çıkarmıştım ve işte o günden sonra pek de memnun olmadığım bir dizi problemle karşılaşmıştım. Özellikle rehber uygulaması ciddi problemler yaşatıyordu. Ara ara ekran donuyor, rehbere girilemez oluyor ve hatta pil birden bire boşalıveriyordu. 

Dün ise 4.4.2 güncellemesini yükledim bir umutla ve acaba dertlerime derman olur mu hevesiyle. 4.4.2 sürümü bir süre önce Fransa'da yayımlanmıştı ve oldukça da olumlu eleştiriler geliyordu. Türkiye'de de bildiğim kadarıyla birkaç ülke ile eş zamanlı olarak iki gün önce yayımlanmaya başlandı. Gördüğüm o ki Samsung bana göre 4.3'te ne kadar çok kötü bir iş çıkarttıysa, 4.4.2 için de aynı oranda çok iyi bir iş çıkartmış;

  • Arayüzde ciddi iyileşmeler var, hız kendisini çok net bir şekilde hissettiriyor.
  • Rehber problemiyle upgrade sonrası karşılaşmadım fakat zaten her gün olan birşey değildi, biraz daha zamana ihtiyacı var kesin karar verilmesi için.
  • Pil ömrü konusunda net bir fark hissedemedim.

Özetle; şu ana kadarki izlenimlerim bir önceki sürüme göre oldukça başarılı bir iş çıkarıldığı yönünde.

Service Oriented Architecture (SOA)

by Cem Kefeli 6. Ekim 2013 14:29

Service Oriented Architecture (SOA)Müşterilere verilen hizmetlerin birer servis olarak düşünülmeye başlamasını ve SOA (Service Oriented Architecture) yaklaşımını birbirlerini tamamlayan, bir elmanın iki parçası gibi düşünebiliriz. Bu bir dönüşüm... Uygulama/sistem temelli bir yaklaşım yerine servis kavramı üzerine inşa edilen bu konseptin çok anlamlı bir gerekçesi de var aslında. Bu gerekçeyi basit anlamda ele alalım;

Müşteriler almış oldukları hizmetin hangi uygulamadan hangi sistemden sağlandığını ve bu hizmetin teknolojideki karşılığını tabiki bilmiyorlar. Ama biliyor oldukları en önemli veri, örneğin telekomünikasyon sektörü için ‘Telefon numarası yönlendirme hizmeti’ aldıkları ya da örneğin bankacılık sektörü için ‘Vadeli hesap oluşturma’ hizmeti aldıkları diyebiliriz. Sunulan çeşitli hizmetlerin teknolojik karşılığı olarak bu işi gerçekleştiren uygulamalar dünyasına şimdi tekrar dönelim. Müşterinin almış olduğu bu hizmetlerin her birinin karşısında bir IT/NW servisi bulunuyor. Bu servisler de farklı farklı uygulamalar, farklı farklı sistemler üzerine dağıtılmış halde bulunabiliyor. Yani müşteriye verilen bir hizmetin mutlaka tek bir uygulama üzerinden sunulması gibi bir zorlama yok. Hatta tam tersine günümüzde işler kompleks bir hal aldığı ve her hizmeti tek bir uygulama üzerinde toplamanın imkan dahilinde olmadığı bir noktaya geldiğimiz için bir servisi verebilmek amacıyla birden çok uygulama/sistem/servis senkron ya da asenkron bir şekilde iş yapmak durumunda kalıyor. Dolayısıyla en başa dönecek olursak, bugünün koşullarının ve iş gereksinimlerinin getirmiş olduğu doğal bir sonuçtur aslında SOA yaklaşımının oluşması. Madem müşteri servis temelli hizmet alıyor, aldığı hizmet kompleks ve iş ihtiyaçlarına göre değişiyor o halde bu hizmetin karşılığındaki teknolojik yapının da servis temelli bir yaklaşım üzerine temellenmesi daha sağlıklı olacaktır. Sonuç olarak bir tanım ortaya koymamız gekirse;

SOA, iş gereksinimlerini esnek bir şekilde karşılayabilmek amacıyla her birisi kendi işinde özelleşmiş, tanımları da net bir şekilde ortaya koyulmuş servislerin birbiri ile uyum içinde çalışmasını sağlayan bir orkestrasyondur.

Dilimiz döndüğünce bir tanım ortaya koyduğumuza göre artık bu tanımın içerdiği söyleme biraz daha yakından bakabiliriz;

İş gereksinimleri
SOA, günün birinde teknoloji ile ilgilenen birkaç mühendisin çay sohbetinde ‘Hadi bizim şu mimarimizi bir değiştirilim!’ düşüncesiyle ortaya çıkan bir konsept olarak düşünülmemelidir. Bu noktaya gelinmesini sağlayan yegane etmen yine iş gereksinimleridir. Yani bu düşünce "Yapılan işi nasıl daha düzenli, esnek ve yüksek çıktı alacak şekilde tasarlayabiliriz?" sorusuna cevap olarak doğmuştur.

Esnek
SOA, yinelenen yapıları pek sevmez. Bir servis, birden fazla servis tarafından kullanılabilir. Yani bir servis, yalnızca tek bir başka servis tarafından kullanılması amacıyla yazılmıyor. Süreçler de zaten bu felsefeye göre tasarlanırlar ki bir iş isteği sonucunda yapılacak değişiklik kolayca tüm servislerde aktif olabilisin. Dolayısıyla irili ufaklı birçok servisin varlığı, değişiklik yapılması ve süreçlerin güncellenmesi aşamasında esneklik sağlamaktadır. SOA, iş yapma, iş değiştirme becerisine hız kazandırmaktadır. Fazlası...

Hakkımda...

Cem KEFELİ

Electronics and
Telecommunication Eng.
devamı...


Son yapılan yorumlar...

Comment RSS

Yasal bir uyarı...

Disclaimer"Bu web sitesinde görmüş olduğunuz bilgilerin, dokümanların ve diğer materyallerin kullanılmasından doğabilecek hiç bir sorumluluktan site sahibi sorumlu tutulamaz. Web sitesi içerisinde yer alan yazılar, yorumlar, resimler ve diğer tüm içerikler yalnızca sahibinin görüşünü yansıtmakta olup içeriğin sahibi kişilerin çalıştığı kurumları bağlayıcı hiç bir nitelik taşımamaktadır. Yapılan tüm alıntılar mutlaka kaynak gösterilerek verilmeye çalışılmaktadır. Web sitesi içerisinde bulunan ilgili materyaller, ilgili yasal kurumlar tarafından uygun görülmemesi durumda kaldırılacaktır."
General