Operatörler; belirli veri türleri arasında ilişki kuran, onları bir sonuca ulaştıran yapılardır. Hemen hemen hergün kullandığımız aritmetik işlemlerdeki toplama(+), çıkartma(-), çarpma(*) ve bölme(/) işlemlerini ifade ettiğimiz simgeler; yada mantıksal işlemlerde kullandığımız or(veya), and(ve), not(değil) vb. gibi simgesel ifadelere operatörler denilebilir. Bildiğiniz gibi; operatörler veri türleri üzerinde üstlerine düşen mantıksal yada matematiksel işlemleri yaparak bir sonucun üretilmesini sağlarlar. Operatörlerin bu vazifelerini, gerek günlük yaşantımızda; gerekse de programlama hayatımızda sıklıkla kullanırız. Programlama ortamlarında yaşadığımız tecrübeler gereği operatörlerimizi düzgün veritipleri ile kullanırız. Örneğin toplama operatörü; sağındaki ve solundaki verilerin toplanması amacına hizmet eder. Ancak; toplama operatörünün sol ve sağındaki değerlerin sayısal olması yada alfasayısal olması durumlarında toplamanın neticesi farklılık arzeder. Basit bir örnek verelim;

var
  iLeft, iRight, iTotal : Integer;
  sLeft, sRight, sTotal : String;
begin
  iLeft := 10;
  iRight := 20;
  iTotal := iLeft + iRight;

  sLeft := 'Operator ';
  sRight := 'Overloading';
  sTotal := sLeft + sRight;
end;

Yukarıda gördüğünüz basit örnekte, aynı operatör(+) farklı sonuçlara hizmet etmektedir. Birinci durumda sonucumuz “30″ olurken; ikinci durumda sonuç “Operator Overloading” olmaktadır. Hemen hemen hiçbirimiz; iki farklı veri türünü aynı operatöre vermeyiz. Örneğin hiçbirimiz; bir sayı ile bir string ifadeyi toplamayız. Ancak bazı durumlarda, bir veri türü ile bir başka veri türünü herhangi bir operatöre vererek işlemek isteyebiliriz. Bu gibi durumlarda, genellikle derleyicimiz bizleri uyaracak bir warning vermekle yetinir. Ancak bazı durumlarda yaptığımız işlemlerde beklediğimizin dışında sonuçlar gördüğümüz de olur. Örneğin;

var
  bLeft, bRight, bTotal : Byte;
  wLeft,wRight,wTotal : Word;
begin
  bLeft := High(Byte); // 255
  bRight:= High(Byte); // 255
  bTotal:= bLeft + bRight; // ??

  wLeft := High(Word); // 65.535
  wRight:= High(Word); // 65.535
  wTotal:= wLeft + wRight; // ??
end;

Yukarıdaki örneğimizde 3 adet Byte ve Word değişken tanımlanıyor ve bu değişkenlerden Left ve Right olanlara o değişken tipinin alabileceği maksimum değer atanıyor. Ardından bu değişkenler birbirleri ile toplanıyor. Bu durumda Byte değişkenlerin toplanmasından elde edilecek değerin; 255 + 255 = 510 olması ve Word değişkenlerin toplanmasından elde edilecek değerin de 65.535 + 65.535 = 131.070 olması bekleniyor. Ancak durum tamamen bunun dışında sonuçlanıyor. Byte değerlerin toplanmasından elde edilen sonucun 254 olduğunu ve Word değerlerin toplanmasından elde edilen sonucun ise; 65.534 olduğunu görüyoruz.

Eminim buna benzer sıkıntılara daha önceleri rastlamışsınızdır. Bu gibi sorunlar tespit edilmesi son derece güç sorunlar olduğu için bu hususa da değinmeden geçmek istemedim. Bu garip durumun aslında son derece mantıklı bir açıklaması var. Bildiğiniz gibi bir Byte veri türü; içinde en yüksek değer olarak 255 sayısını tutabilir. Byte türündeki bir değişkene 255 + 255 ‘lik bir verinin atanmaya çalışılması durumunda; 510 olması gereken veri kırpılarak atanır. Kırpılma işlemi; ilgili sonucun 255 + 1 ‘e göre mod alınmasından kalan değerdir. Byte ve Word değişkenlerimizdeki durum aşağıdaki gibi olur;

var
  bLeft, bRight, bTotal : Byte;
  wLeft, wRight, wTotal : Word;
begin
  bLeft := High(Byte); // 255
  bRight := High(Byte); // 255
  bTotal := bLeft + bRight; // İşte tam bu noktada; 510 mod (255 + 1) işlemi yapılıyor. Bu da 254 sonucunu verecektir.

  wLeft := High(Word); // 65.535
  wRight := High(Word); // 65.535
  wTotal := wLeft + wRight; // Bu noktada da; 131.070 mod (65.535 + 1) işlemi yapılıyor. Bu işlemin sonucu da 65.534 sonucunu verecektir.
end;

Gördüğünüz gibi; yaptığımız aritmetik işlemlerde artı operatörünün her iki tarafındaki veri türü ve sonucun atanacağı veri türüde birbirine eşit olmasına rağmen beklenen sonucun aksi bir durum ile karşılaştık. Buna benzer bir başka garip durumu daha sizlerle paylaşmak isterim. Aşağıdaki örneği lütfen dikkatlice inceleyiniz:

function Replicate(const Value : String; const Count : Cardinal) : String;
var
  Counter : Cardinal;
begin
  Result := Value;
  for Counter := 0 to Count - 1 do Result := Result + Value;
end;
..
..
..
var
  sRetValue : String;
begin
  sRetValue := Replicate('Merhaba ', 0);
  ShowMessage(sRetValue);
end;

Yukarıda örneğini verdiğimiz kodda, Replicate metodunun içindeki döngünün asla çalışmayacağını düşünerek(0′dan -1′e) metodumuzun sadece “Merhaba” döndürmesini bekleriz. Oysaki durum burada da farklıdır. Örneğimizi çalıştırıp denerseniz, kodun asla ShowMessage satırına inemediğini göreceksiniz. Tabii uzun bir sabrınız yok ise. Peki burada ne gibi bir gariplik olmuştur ?

Dikkat ederseniz eğer, Replicate metoduna geçilen Count parametresi Cardinal veri tipinden tanımlanmıştır. Ve bu veritipi, Low(Cardinal)..High(Cardinal) aralığında yani 0 ila 4.294.967.295 arasında değer alacaktır. Veri aralığından gözlemleyeceğiniz gibi, bu veri türü negatif değerler alamamaktadır. Oysaki Replicate(‘Merhaba’, 0) kullanımı sayıyı negatif aralığa sürüklemek isteyecektir(0-1). Bu gibi bir durumda; döngümüz sıfırdan 4.294.967.295 değerine kadar dönmeye çalışacaktır. Gördüğünüz gibi pozitif sayı aralığındaki değişkenlere negatif değer atama çabaları, veri tipinin alabileceği maximum değere set edilmesini sağlar.

Bu sebeple; veri tipleri üzerinde aritmatiksel yada mantıksal operatörleri kullanırken dikkatli olmakta fayda vardır. Takdir edersiniz ki; bu tip hataları tespit etmek son derece zordur. Bu sebeple kodlarımızı yazarken bu hususları göz önünde bulundurmak programlarımızın stabilitesi ve bizim akıl sağlığımız açısından son derece önemlidir.

Bahsedilen bu iki garip durum senaryosunun aslında Operator Overloading hususu ile direkt bir ilgisi yok. Ancak; bu konuyu anlatırken hatalara neden olabilecek bu dikkat edilesi hususu da ilginize sunmak istedim.

Çevresinde dolaştığımız ancak henüz kendisine temasta bulunmadığımız Operator Overloading konusunda da biraz konuşmanın zamanı geldi sanırım. Operatörleri aşırı yüklemek; kısaca derleyiciye ilgili işlemin sonuçlarını “ben yöneteceğim” demektir! Bu iddialı sözü, genellikle programlarımızı daha da basitleştirebilmek adına söyleriz. Sıklıkla başka bir kullanım amacına rastlanmaz. Ancak; biz makalemizde Operator Overloading’i Delphi’ye yeni tipler kazandırmak amacı ile kullanacağız.

.Net dillerinde; Operator Overloading hem sınıflara hemde struct denilen Delphi’de record’a karşılık gelen yapılara uygulanabilmektedir. Ancak; Delphi’de Garbage Collection gibi bir çöp toplama mekanizmasının var olmaması nedeni ile henüz bu özellik sadece record’lar ile sınırlıdır. Yeni veritürlerimizden NewString türüne girmeden evvel, string türlerle ilgili bazı örnekler vermeye çalışalım:

var
  sVal : String;
  iLen : Integer;
begin
  sVal := 'Merhaba ';
  sVal := sVal * 3; // Geçersiz

  iLen := sVal.Length; // Geçersiz
  sVal := sVal.Replace('a', 'x'); // Geçersiz
  sVal := -sVal; // Geçersiz
end;

Örneğimiz de; sVal string türünde bir değişken tanımlanmış ardından bu değişkene “Merhaba ” ifadesi atanmıştır. Ardından hepimize saçma görünebilecek bir işlem ile bir string değişken 3 ile çarpılmaya çalışılmıştır. Burada amaçlanan 3 adet “Merhaba ” string’inin yanyana getirilmesidir. Ancak derleyicimiz bize; “Incompatible types: string and Integer” gibi bir hata ile yanıt vermiştir.

Ardından, sVal değişkenimiz üzerinde Length isimli bir metodun çağrılması istenmiştir. Bu da geçersiz bir kullanımdır. Çünkü string veri türü; Delphi’de bir sınıf yada bir record değildir dolayısı ile metod çağrımlarını desteklemez. Buna benzer bir şekilde Replace metodu da çalışmayacaktır. Son kullanım tarzımızda sVal değişkenimizin içindeki değerin ters çevrilmesi(Reverse) arzulanmıştır. Ancak şu anki imkanlarımız ile bu da mümkün değildir.

Tüm bu işlemleri yapabilmek için elbetteki pek çok string metodu bulunmaktadır. Ancak biz bu metodları hatırımızda tutmak yerine .Net framework’teki mantalitede kullanabilmek istersek ne yapmalıyız ? İşte tam bu noktada Record’lar ve operator overloading konusuna girmiş bulunuyoruz. Daha fazla ilerlemeden önce; Delphi’de tanımlı olan operatörlerimizin neler olduğuna bir bakalım:

Gördüğünüz gibi pek çok tanımlı operatörümüz var. Bu operatörlerimizin tek tek ne olduğunu ifade etmeden önce neden yeni bir string tipi tanımlamak istediğimizi ve bize getirilerinin neler olabileceği hakkında tüm söylediklerimize ek olarak bir kaç kelam daha etmekte fayda olabilir.

.Net dillerinde; bir string değişken tanımlandığında o string türü ile ilgili işlem yapabilecek metodların hepsine nokta(.) ya basarak erişebilme gücüne sahip olursunuz. Böylece bir veri türü üzerinde ne gibi işlemler yapılabileceğini bir bakışta gözlemleyebilirsiniz. Aynı zamanda; o veri türü ile ilgili işlem yapan metodların isimlerini ezberlemek yada hangi unit’te tanımlandıklarını hatırlamak ve uses bloğunda referans vermek durumunda kalmazsınız. Ayrıca; operator overloading herhangi bir veri türü ile yapılması derleyici tarafından yasaklanmış işlemleri kodlamanıza da imkan sağlayacaktır(Bir string’in tersini almak için başına eksi koymak gibi).

Bu faydalar; operator overloading kavramını programlarımızda bir yardımcı unsur olarak kullanmamız için yeterli olabilecek sebeplerdendir. Tüm bu teorik verilerin ışığında artık kodlamaya geçmeye başlayabiliriz. Tahmin edebileceğiniz gibi, yeni veri türümüz string veri türü ile iletişim kurabilen, ek özellikler getirebilen bir record olacaktır.

type
  NewString = record
  end;

..
..
var
  Old : String;
  New : NewString;
begin
  Old := 'Merhaba';
  New := Old;
end;

Örneğimizde NewString isminde bir record tanımladık ve içinde herhangi bir metod tanımlamadık. Ardından Newstring türündeki değişkenimize string türündeki değişkenimizi atamaya çalıştık. Ancak; derleyici tam bu satırda bize, “Incompatible types: ‘NewString’ and ’string’” hatası verecektir. Her iki tipin birbirine nasıl atanacağı bu noktada derleyici tarafından bilinmemektedir. Bu noktada yapacağımız şey; derleyiciye yeni tipimizin string veri türü ile atama sırasında ne gibi bir işlem yapması gerektiği hususunda bilgi vermektir. Kullanmamız gereken Implicit adındaki operatör metodudur. Implicit operatörü yeni tanımladığımız record’umuza atama yapılacağı sırada ne gibi bir kod çalıştırmamız gerektiğini söyleyecektir. Yeni kodumuz aşağıdaki gibi olacaktır.

type
  NewString = record
  private
    fData : String;
  public
    class operator Implicit(const Left : String) : NewString;
  end;

implementatiton

class operator NewString.Implicit(const Left : String) : NewString;
begin
  Result.fData := Left;
end;
..
..
var
  Old : String;
  New : NewString;
begin
  Old := 'Merhaba';
  New := Old;
end;

Gördüğünüz gibi NewString record’umuz içinde private bölümünde fData isminde ve string türünde bir değişken tanımladık. Ardından; NewString veri türümüze atama yapmak istediğimiz veri türü string olduğu için Implicit operatörünü string verileri alabilecek şekilde tanımladık. Bu aşamada; New := Old; ataması Implicit kodumuza dallanılmasına sebep olacaktır. Implicit operatörü bilinçsiz tür dönüşüm operatörü olarak da bilinir. New adlı ve NewString türlü değişkenimize string türündeki verilerin atanmaya çalışılması her zaman Implicit metodumuza başvurulmasına neden olacaktır. Ancak; New := 123; gibi bir atama yine derleyici tarafından bir hata ile neticelenecektir. Çünkü Integer veri türü ile atama uyumluluğuna sahip değiliz. Integer veri türü ile ilgili bir atamanında geçerli olması isteniyorsa; Integer veri türü içinde bir Implicit metodunun yazılması icap edecektir.

Explicit ise; bilinçli tür dönüşüm operatörüdür. Bazen veri türlerimizi başka bir veri türüne dönüştürmek için casting yaparız. Bu tarz durumlarda explicit operatöründe yazdığımız kodlar devreye girecektir. Örneğin; Old := String(New); türündeki bir kullanım explicit operatör çağrımına neden olacaktır. O halde explicit operatörümüzü de ekleyerek ilerlemeye devam edelim:

type
  NewString = record
  private
    fData : String;
  public
    class operator Implicit(const Left : String) : NewString;
    class operator Explicit(const Left : NewString) : String;
  end;

implementatiton

class operator NewString.Implicit(const Left : String) : NewString;
begin
  Result.fData := Left;
end;

class operator NewString.Explicit(const Left : NewString) : String;
begin
  Result := Left.fData;
end;

..
..
var
  Old : String;
  New : NewString;
begin
  Old := 'Merhaba';
  New := Old;

  Old := String(New);
end;

String ifadeler sözkonusu olduğunda sık kullandığımız operatörlerden birisi de +(Artı) operatörüdür. Bunun için Delphi’de kullanmamız gereken operatörün Add operatörü olduğunu tahmin edersiniz. Ancak; ilgili tablodan gördüğünüz gibi Add operatörünün kullanılması , Implicit ve Explicit’in kullanımlarından biraz daha farklıdır. Add metodu içine toplanması istenen iki veri türünü de parametre olarak beklemektedir. Biz bu durumda tüm olasılıklara uygun Add metodlarını yazmak durumunda kalırız. Arzu ederseniz onu da kodlayalım;

  NewString = record
  private
    fData : String;
  public
    class operator Implicit(const Left : String) : NewString;
    class operator Explicit(const Left : NewString) : String;

    class operator Add(const Left : String; const Right : NewString) : NewString; // 1.nci metod: New := 'Test' + New; gibi bir kullanım.
    class operator Add(const Left : NewString; const Right : String) : NewString; // 2.nci metod: New := New + 'Test'; gibi bir kullanım.
    class operator Add(const Left : NewString; const Right : NewString) : NewString; // 3.ncü metod: New := New + New; gibi bir kullanım.
  end;

implementatiton

class operator NewString.Implicit(const Left : String) : NewString;
begin
  Result.fData := Left;
end;

class operator NewString.Explicit(const Left : NewString) : String;
begin
  Result := Left.fData;
end;

class operator NewString.Add(const Left : String; const Right : NewString) : NewString;
begin
  Result.fData := Left + Right.fData;
end;

class operator NewString.Add(const Left : NewString; const Right : String) : NewString;
begin
  Result.fData := Left.fData + Right;
end;

class operator NewString.Add(const Left : NewString; const Right : NewString) : NewString;
begin
  Result.fData := Left.fData + Right.fData;
end;

..
..
var
  Old : String;
  New : NewString;
begin
  Old := 'Merhaba';
  New := Old;

  Old := String(New);

  New := 'Dünya ' + New; // "Dünya Merhaba" sonucunu elde edeceğiz. 1.nci metod çağrılacaktır.
  New := New + ' Dünya'; // "Merhaba Dünya" sonucunu elde edeceğiz. 2.nci metod çağrılacaktır.
  New := New + New;      // "MerhabaMerhaba" sonucunu elde edeceğiz. 3.ncü metod çağrılacaktır.
end;

Add operatöründe yada onun gibi birden fazla veri türü ile işlem yapan diğer operatör metodlarında yegane kural; geçilmesi gereken parametrelerden en az bir tanesinin NewString türünde olması gerektiğidir. Kısacası aşağıdaki gibi bir tanıma sahip olamayız:

type
  NewString = record
  ..
  ..
    class operator Add(const Left : String; const Right : String); // Her iki parametre türü de string olduğu için kabul edilmez.!
  end;

String veri türlerinde çıkartma işlemine pek sık rastlanmadığı için Subtract operatörü ile ilgilenmeyeceğiz ancak onun da Add operatöründen farklı olmadığını bilmenizi isterim. Başlarda verdiğimiz örneklerde bir string ifadeyi belli bir sayı ile çarparak o string’den birden fazla elde etmek ve string ifadenin başına eksi(-) operatörünü koyarak ilgili string ifadeyi ters çevirmeyi denemiş ve hata ile neticeleneceğini ifade etmiştik. Şimdi gelin, bu operatörleri de yeni veri türümüz olan NewString için kodlayalım. Kullanacağımız operatörler tahmin edeceğiniz gibi, Multiply ve Negative operatörleri olacak;

class operator NewString.Multiply(const Left : NewString; const Right : Integer) : NewString; // 1.nci metod
begin
  Result.fData := DupeString(Left.fData, Right);
end;

class operator NewString.Multiply(const Left : Integer; const Right : NewString) : NewString; // 2.nci metod
begin
  Result.fData := DupeString(Right.fData, Left);
end;

class operator NewString.Negative(const Left : NewString) : NewString;
begin
  Result.fData := ReverseString(Left.fData);
end;

..
..
var
  New : NewString;
begin
  New := 'Merhaba'; // Implicit çağrımına neden olur.
  New := New * 3; // "MerhabaMerhabaMerhaba" sonucunu döndürür. 1.nci metod çağrılacaktır.

  New := 'Dünya'; // Implicit çağrımına neden olur.
  New := 3 * New; // "DünyaDünyaDünya" sonucunu döndürür. 2.nci metod çağrılacaktır.

  New := 'Merhaba Dünya'; // Implicit çağrımına neden olur.
  New := -New; // Negative çağrımına neden olur. "aynüD abahreM" sonucunu döndürecektir.
end;

Bunların ardından olmazsa olmazlarımızdan Equal ve NotEqual operatör metodlarını kodlamamız gerekiyor. Bu metodların kodlanmaması NewString veri türümüz için karşılaştırma işlemleri yapamamamız anlamını taşıyacaktır.

class operator NewString.Equal(const Left: String; // 1.nci metod
  const Right: NewString): Boolean;
begin
  Result := Left = Right.fData;
end;

class operator NewString.Equal(const Left: NewString; const Right: String): Boolean; // 2.nci metod
begin
  Result := Left.fData = Right;
end;

class operator NewString.Equal(const Left, Right: NewString): Boolean; // 3.ncü metod
begin
  Result := Left.fData = Right.fData;
end;

class operator NewString.NotEqual(const Left, Right: NewString): Boolean; // 1.nci metod
begin
  Result := Left.fData <> Right.fData;
end;

class operator NewString.NotEqual(const Left: NewString; // 2.nci metod
  const Right: String): Boolean;
begin
  Result := Left.fData <> Right;
end;

class operator NewString.NotEqual(const Left: String; // 3.ncü metod
  const Right: NewString): Boolean;
begin
  Result := Left <> Right.fData;
end;
..
..
var
  New, New2 : NewString;
begin
  New := 'Merhaba';
  New2:= 'Merhaba';

  if 'Merhaba' = New then ShowMessage('Merhaba = New'); // 1.nci metod çağrılacaktır.
  if New = 'Merhaba' then ShowMessage('New = Merhaba'); // 2.nci metod çağrılacaktır.
  if New = New2 then ShowMessage('New = New2'); // 3.ncü metod çağrılacaktır.

  if New <> New2 then ShowMessage('New <> New2'); // 1.nci metod çağrılacaktır.
  if New <> 'Merhaba' then ShowMessage('New <> Merhaba'); // 2.nci metod çağrılacaktır.
  if 'Merhaba' <> New then ShowMessage('Merhaba <> New'); // 3.ncü metod çağrılacaktır.
end;

Diğer operatörlerimiz belki string veri türümüz için anlamlı olmayacaktır. Ancak, sizler kendi yazacağınız veri türlerinde ilgili operatör metodlarını da kullanabilirsiniz. Ben; sıklıkla eksikliğini hissettiğimiz String ve TDatetime veri türleri ile ilgili yeni tip tanımına gitmeyi faydalı buldum. Yazmış olduğum yeni tipleri indirebilmeniz için makalenin sonunda bir link vereceğim.

Makalemizi neticelendirmeden evvel yeni tiplerimiz ile neler yapabileceğimize dair küçük bir kaç örnek vermek faydalı olacaktır:

procedure Log(const Message : String);
begin
  form1.Memo1.Lines.Add(Message);
end;

var
  New : NewString;
  arr   : TList<Char>;
  arr2 : TList<String>;
  ch   : Char;
  str : String;

  Len,
  Index : Integer;
begin
  New := 'Merhaba Dünya';
  Log(New.ToString);

  arr := New.ToChararray;
  for ch in arr do Log(ch);

  arr := New.ToCharArray(5, 6);
  for ch in arr do Log(ch);

  if New.Contains('Merhaba') then Log('Merhaba bulundu');
  if New.EndsWith('Dünya') then Log('Dünya stringi ile bitiyor');
  if New.StartsWith('Merhaba') then Log('Merhaba stringi ile başlıyor');
  Index := New.IndexOf('Dünya');
  Len := New.Length;
  New := New.Trim;
  New := New.Replace('a', 'x');
  New := New.SubString(5, 5);
  New := New.ToUpper;
  New := New.ToLower;

  New := 'Merhaba,Dünya';
  arr2 := New.Split(',');
  for str in arr2 do Log(str); // Merhaba ve Dünya
end;

var
  NewDT : NewDateTime;
  dt : TDateTime;
begin
  NewDT := Now;
  NewDT := Date;
  NewDT := 'bugün';
  NewDT := 'yarın';
  NewDT := '+5y'; // Bugünün tarihinden 5 yıl sonrası.
  NewDT := Now + '-3y +5a -7g +6s +15dk +30sn'; // Bugünden 3 yıl 7 gün öncesinden 5 ay 6 saat 15 dakika 30 saniye sonrası.
  NewDT := Date + 5; // 5 gün sonrası.
  Log(NewDT.ToString);
  Log(InttoStr(NewDT.Day));
  Log(InttoStr(NewDT.Month));
  Log(InttoStr(NewDT.Year));
  Log(InttoStr(NewDT.Hour));
  Log(InttoStr(NewDT.Minute));
  Log(InttoStr(NewDT.Second));
  Log(InttoStr(NewDT.MilliSecond));

  NewDT.Year := NewDT.Year + 3;
  dt := NewDT.ToDateTime;
  Log(DateToStr(dt));

  Inc(NewDT);
  Dec(NewDT);

  NewDT := NewDT - 7;
  NewDT := NewDT - '3g 5s';
end;

NewDateTime ve Newstring isimli dosyaları da buradan indirebilirsiniz.

Sevgiler, saygılar..

Hedefimize ilerlerken ilk durağımız olan Interface’lerde biraz durup soluklanalım ve bu kavramın ne olduğu yada ne olmadığı; neleri başarıp neleri başaramayacağı; neden var olduğu ve nerelerde kullanabileceğimiz hakkında nacizane bilgilerimiz ile konunun karanlık köşelerine ışık tutmaya gayret edelim.

Interface kelimesi dilimizde genellikle “Arayüz” yada “Arabirim” olarak kullanılmaktadır. Pek çok programcımız için Interface’ler ya çok basit bir yapı olarak ya da COM programlamanın fıtratı gereği çok karmaşık bir yapı olarak algılanır. Aslında her ikisi de doğrudur. Yapısal görünümü itibari ile son derece basit görünen Interface’ler aslında yapabildikleri ve nasıl yaptıkları itibarı ile de son derece kompleks yapılardır. Bir interface görünüm ve yapı itibari ile bir sınıfa çok benzer. Ancak elbette bu makaleye konu olan pek çok farklılıkları da mevcuttur. Arzu ederseniz makalemizde ilerlemeden önce çok basit bir interface tanımının Delphi’deki yapısını görelim ve ardından ilerlemeye devam edelim:

  IFlyable = interface
  end;

Gördüğünüz gibi bir sınıf tanımına son derece benziyor. Ancak bazı farklılıkları var. IFlyable(uçabilen) arabiriminin tanımlamasında “class” ayrılmış sözcüğü yerine “interface” sözcüğünün geçtiğini gözlemliyoruz. Şu anda gözlemleyebildiğimiz başka bir fark bulunmuyor. Aslında interface’ler özet sınıf adını verdiğimiz abstract sınıflara çok benzerler. Abstract sınıflar, kendisini miras alacak sınıflar için ileride kullanılmasının zorunlu olduğu metodların birer özetlerini içerirler. Ancak bu sınıflar aynı zamanda gerçek kod bloklarına da ev sahipliği yapabilirler. Interface’lerin ve abstract(özet) sınıfların ortak özellikleri; kendilerini kullanacak olan alt sınıflarda tanımlanması gereken metodların şablonlarına ev sahipliği yapmaktır.

Bir interface’te yada abstract sınıfta tanımlanmış olan bir metod; bu interface yada abstract sınıfı kullanmak isteyen alt sınıflarda kesinlikle tanımlanmalıdır(Gerçekte bir abstract sınıf içinde tanımlı olan bir metod, bu abstract sınıfı miras alan alt sınıfta tanımlanmayabilir, ancak alt sınıftaki metod çağrımı bir hataya neden olacağı için genellikle tanımlanmak zorundadır.). Aksi durumda derleyici kodunuzu derlemenize izin vermez. Şu aşamaya kadar söylediklerimizi küçük bir örnek ile göstermeye çalışalım;

  IFlyable = interface
    procedure Fly;
  end;

  TPlaneInterface = class(TInterfacedObject, IFlyable)
    procedure Fly;
  end;

  TFlyable = class abstract
    procedure Fly; virtual; abstract;
  end;

  TPlaneClass = class(TFlyable)
    procedure Fly; override;
  end;

Yukarıdaki kısa kod örneğimizde bir interface ve o interface’i implemente(uygulayan) eden bir sınıf; bir abstract sınıf ve o sınıfın bir mirasçısını görüyorsunuz. Tanımlarda bazı farklılıklar var. IFlyable interface’i içindeki Fly metodu için editörümüzde herhangi bir kod yazmanıza gerek yoktur. Ancak bu interface’i implemente edecek olan sınıfta (TPlaneInterface) Fly metodunun yazılması zorunludur. Bu tanıma çok benzer bir şekilde TFlyable isimli abstract sınıfımızında kod editöründe herhangi bir kodu yoktur ve interface’lerde olduğu gibi abstract sınıfı miras alan (TPlaneClass) sınıflarda Fly metodunun yeniden tanımlanması icap eder. Eğer TPlaneClass sınıfı içinde Fly metodunu yeniden tanımlamazsanız derleyici kodunuzu düzgün bir şekilde derleyebilecektir ancak çalışma anında Fly metodunu çağırırsanız bir “Abstract Error” hatası alırsınız. Bu hataların oluşmasına mani olmak için, abstract sınıflarda genellikle “virtual; abstract” olarak tanımlanan metodların alt sınıflarda yeniden tanımlanması gerekir.

Bu bağlamda interface’ler ve abstract sınıflar birbirlerine son derece benzerler. Genellikle programcılarımız abstract sınıfların varlığı karşısında interface’lerin karmaşık ve gereksiz mekanizmalar olduğunu düşünürler. Abstract sınıflar interfacelerden farklı olarak içlerinde gerçek kod parçacıkları da bulundurabilirler. Bu yetenekleri ile interface’lerden daha geniş bir kullanıma sahip oldukları ve aynı zamanda daha nesnesel ve kolay oldukları düşünülür. Bu elbette bir bakış açısıdır, ancak tamamiyle doğru değildir.

Şimdi bir abstract sınıfın içinde gerçek kod parçalarının da olabileceğine bir örnek verelim;

  TFlyable = class abstract
   private
    fField : Integer;

    procedure Fly; virtual; abstract;
   public
    procedure RealCode; virtual;
  end;
 //...
 //...
  procedure TFlyable.RealCode;
  begin
    //..
    //..
  end;

Görüldüğü üzere, bir abstract sınıfın içinde hem şablon bir metod hemde gerçek bir kod yazabildik. Aynı zamanda public, private gibi erişim belirleyicileri kullanabildik ve ihtiyacımız olan değişkenleri de tanımlayabildik.

Evet bu noktaya kadar bir interface’in yada bir abstract sınıfın neye benzediği yönünde küçük bazı örnekler gördük. Ancak interface’in neden var olduğu, abstract ve interface’lerin birbirlerine alternatifmi oldukları hakkında henüz herhangi bir yorum yapmadık.

Interface’ler; içlerinde istediğiniz kadar metod tanımlayabileceğiniz ve bu metodlar için kod yazmanıza gerek olmayan sanal yapılardır. Bu interface’i implemente edecek olan sınıflarınızın yeteneklerinin ne olduğunu özetleyebilen özet yapılar olarak düşünülebilir. Interface’ler içlerinde metod tanımlarını barındırabilirler ancak, değişken tanımına yada erişim kısıtlayıcılara sahip olamazlar. Yani; bir interface’in içinde herhangi bir türden değişken tanımlayamazsınız , tanımlayabildiğiniz tüm metodlar; public olarak kabul görür ve interface’in içinde public, private, protected kullanamazsınız. Bu özellikleri ile abstract sınıflardan ayrılırlar.

Aynı zamanda Interface’ler bir sınıftan yada bir record’dan türeyemezler. Bir Interface; sadece bir başka interface’den türeyebilir. Benzer bir şekilde herhangi bir sınıfta direkt olarak bir interface’den türeyemez.

Geçersiz kullanımlara kısaca bir göz atalım arzu ederseniz;

  ITest = interface
  end;

  IFlyable = interface(TObject) // Geçersiz
  end;

  IFlyable = interface(ITest) // Geçerli
  end;

  TFlyable = class abstract(IFlyable) // Geçersiz
  end;

  TFlyable = class abstract// Geçerli
  end;

  TFlyable = class abstract(TComponent) // Geçerli
  end;

  TFlyable = class abstract(TInterfacedObject, IFlyable) // Geçerli
  end;

Görüldüğü gibi, bir interface bir sınıftan miras alınarak tanımlanamaz. Ancak ve ancak bir başka interface’i miras alabilir. Oysaki sınıf tanımlarında abstract olsun yada olmasın durum biraz daha farklıdır. Bir sınıf bir interface’i direkt olarak miras alamaz ancak bir yardımcı sınıf vasıtası ile(TInterfacedObject) interface’leri de miras alabilir.

Tüm bu anlatılanlar ışığında kısa bir özet vermek sanırım iyi olacaktır.

• Interface’ler şablon tanımlarıdır, ve gerçek kod parçacıkları içermezler.
• Interface’ler içlerinde değişken tanımlarına ve erişim kısıtlayıcılarına(public, private vb.) sahip olamazlar.
• Interface’ler sınıflardan miras alınamazlar, sadece bir başka interface’den miras alınabilirler.
• Interface’leri implemente eden sınıflarda interface’in sahip olduğu tüm metodların uygulanması gerekir.

• Abstract sınıflar şablon tanımlarıdır ama gerçek kod parçacıkları da içerebilirler.
• Abstract sınıflar içlerinde değişken tanımlarına ve erişim kısıtlayıcılarına(public, private vb.) sahip olabilirler.
• Abstract sınıflar interfacelerden direkt olarak miras alınamazlar, Interface’leri implemente edebilmeleri için TInterfacedObject gibi bir sınıfı kullanmaları gerekir.
• Abstract sınıfları implemente eden sınıflarda abstract sınıfın içinde tanımlı olan tüm virtual; abstract; metodların implemente edilmesi önerilir ancak bunun aksi bir durum derleyici tarafından da kabul görür. Bu gibi bir durumda derleyici abstract sınıfı miras alan sınıfı create etmeye çalıştığınız kod bloğu için bir warning mesajı verecektir.

Sanıyorum artık, abstract sınıflar ve interface’lerle ilgili az da olsa bir fikir sahibiyiz. Bu iki birbirine yakın kullanım temelde aynı amaca hizmet etmektedir. Ancak birbirinden farklı bir sözdizimine sahiptir. Peki, biz hangi durumlarda hangisini kullanacağız ?

Bu sorunun yanıtı abstract sınıf ve interface ayrımına gidilmesinin nedenlerini izah için yeterli olacaktır. Hepimizin bildiği gibi Delphi, C# gibi diller multiple inheritance adı verilen çoklu kalıtımı desteklemezler. Ancak C++ gibi diller çoklu kalıtıma imkan sağlarlar. Bir sınıfın birden fazla atasının olması gibi bir konseptin Delphi, C# gibi dillerde olmaması belki karmaşanın önüne geçmek içindir. Ancak çoklu kalıtıma ihtiyaç duyduğumuz yerlerde olabilir. Kısa bir örnek vererek daha da anlamlandırmaya çalışalım.

Diyelim ki, taşıtlarla ilgili bir sınıf hiyerarşisi oluşturmak istiyoruz. Bu hiyerarşiyi hem interface ile hem de abstract sınıflar ile yapmaya çalışalım:

// Interfacelerle ilgili tanımlamalar...

  ITasit = interface
    procedure MotoruCalistir;
    procedure MotoruDurdur;
  end;

  IUcabilenTasitlar = interface(ITasit)
    procedure Uc;
  end;

  TUcabilenTasitlar = class(TInterfacedObject, IUcabilenTasitlar)
  public
    procedure MotoruCalistir;
    procedure MotoruDurdur;

    procedure Uc;
  end;

  IYuzebilenTasitlar = interface(ITasit)
    procedure Yuz;
  end;

  TYuzebilenTasitlar = class(TInterfacedObject, IYuzebilenTasitlar)
  public
    procedure MotoruCalistir;
    procedure MotoruDurdur;

    procedure Yuz;
  end;

  IKaradaGidebilenTasitlar = interface(ITasit)
    procedure Yuru;
  end;

  TKaradaGidebilenTasitlar = class(TInterfacedObject, IKaradaGidebilenTasitlar)
  public
    procedure MotoruCalistir;
    procedure MotoruDurdur;

    procedure Yuru;
  end;

// Abstract sınıflarla ilgili tanımlamalar...

  TTasitAbstract = class abstract
  public
    procedure MotoruCalistir; virtual; abstract;
    procedure MotoruDurdur; virtual; abstract;
  end;

  TUcabilenTasitlarAbstract = class abstract(TTasitAbstract)
  public
    procedure Uc; virtual; abstract;
  end;

  TUcabilenTasitlar = class(TUcabilenTasitlarAbstract)
  public
    procedure MotoruCalistir; override;
    procedure MotoruDurdur; override;

    procedure Uc; override;
  end;

  TYuzebilenTasitlarAbstract = class abstract(TTasitAbstract)
  public
    procedure Yuz; virtual; abstract;
  end;

  TYuzebilenTasitlar = class(TYuzebilenTasitlarAbstract)
  public
    procedure MotoruCalistir; override;
    procedure MotoruDurdur; override;

    procedure Yuz; override;
  end;

  TKaradaGidebilenTasitlarAbstract = class abstract(TTasitAbstract)
  public
    procedure Yuru; virtual; abstract;
  end;

  TKaradaGidebilenTasitlar = class(TKaradaGidebilenTasitlarAbstract)
  public
    procedure MotoruCalistir; override;
    procedure MotoruDurdur; override;

    procedure Yuru; override;
  end;

// Interface sınıflarından yada abstract sınıflardan türeyebilen sınıflar

  TUcak = class(TUcabilenTasitlar)
  end;

  TGemi = class(TYuzebilenTasitlar)
  end;

  TAraba = class(TKaradaGidebilenTasitlar)
  end;
..
..
..
var
  BMW, Audi, Mercedes  : TAraba;
  Gemi, Yat, Tekne  : TGemi;
  Piper, Jet, Zeplin  : TUcak;
begin
  BMW := TAraba.Create;
  BMW.Yuru;

  Audi := TAraba.Create;
  Audi.Yuru;

  Mercedes := TAraba.Create;
  Mercedes.Yuru;

  Gemi := TGemi.Create;
  Gemi.Yuz;

  Yat := TGemi.Create;
  Yat.Yuz;

  Tekne := TGemi.Create;
  Tekne.Yuz;

  Piper := TUcak.Create;
  Piper.Uc;

  Jet := TUcak.Create;
  Jet.Uc;

  Zeplin := TUcak.Create;
  Zeplin.Uc;

  BMW.Free;
  Audi.Free;
  Mercedes.Free;

  Gemi.Free;
  Yat.Free;
  Tekne.Free;

  Piper.Free;
  Jet.Free;
  Zeplin.Free;
end;

Yukarıdaki sınıf tanımlarımızda uçabilen, yüzebilen ve karada gidebilen taşıtları hem interface’ler vasıtası ile hem de abstract sınıflar vasıtası ile tanımladık. Ardından TAraba, TGemi ve TUcak sınıflarını bu sınıflardan türettik ve ilgili nesnelerimizi oluşturabildik. Bu aşamaya kadar herhangi bir dizayn problemi ile karşılaşmadık. Ancak; ya hem karada hem denizde gidebilen howercraft türü bir taşıtımız varsa ne yapacağız ? Bu aracı hangi sınıftan türeteceğiz ? Abstract yaklaşımla yapmaya çalıştığımız da aşağıdaki gibi bir kullanıma ihtiyacımız olacak;

  THemKaradaHemDenizdeGidebilenTasitlarAbstract = class abstract(TYuzebilenTasitlarAbstract, TKaradaGidebilenTasitlarAbstract)
  end;

Ancak hepimizin bildiği gibi ne Delphi ne de C# gibi diller bu tarz bir tanımlamaya(Multiple Inheritance) müsaade etmiyorlar. Arzu ederseniz bir de Interface’ler ile yapmaya çalışalım;

  THemKaradaHemDenizdeGidebilenTasitlar = class(TInterfacedObject, IYuzebilenTasitlar, IKaradaGidebilenTasitlar)
   public
    procedure MotoruCalistir; // ITasit interface'inden..
    procedure MotoruDurdur; // ITasit interface'inden..

    procedure Yuz; // IYuzebilenTasitlar interface'inden..
    procedure Yuru; // IKaradaGidebilenTasitlar interface'inden..
 end;
..
..
..
var
  howercraft : THemKaradaHemDenizdeGidebilenTasitlar;
begin
  howercraft := THemKaradaHemDenizdeGidebilenTasitlar.Create;
  howercraft.Yuz;
  howercraft.Yuru;
  howercraft.Free;
end;

Evet, görebildiğiniz gibi Delphi’de interface kullanarak multiple inheritance’ın yollarını açtık. Multiple Inheritance’a ihtiyaç duyulması interface kullanılması için gereken nedenlerden sadece birisidir. Diğer önemli neden, şu ana kadar hiç bahsetmediğimiz Referans Sayma Mekanizmasıdır. Makalemizin bu noktadan sonrası konunun başlığı gereği interface’lere yönelik olacaktır. Şu zamana kadar yazdıklarımız, genelde birbirine karıştırılan yada birbirinin arasındaki farkın çok net olmadığı iki özel teknolojinin zihnimizde daha da netleşebilmesi adına idi.

Referans sayımının detaylarına inmeden önce tüm interface’lerin IInterface arabiriminden türemiş olduğunu söylememiz gerekir. Nasıl ki yeni bir sınıf tanımlarken TMyClass = class tanımı ile TMyClass = class(TObject) tanımı aynı ise; interfacelerde de benzer bir şekilde IMyInterface = interface tanımı ile IMyInterface = interface(IInterface) tanımı aynıdır. Kısacası tüm interface’lerin atası IInterface arabirimidir. Şimdi gelin IInterface arabiriminin Delphi’deki tanımına yakından göz atalım:

  IInterface = interface
    ['{00000000-0000-0000-C000-000000000046}']
    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  end;

IInterface arabiriminin sahip olduğu 3 metodun da birbirinden önemli olduğunu ifade etmek isterim. Hatırlayacağınız üzere, interface tanımlarının bir sınıf tarafından direkt olarak miras alınmasının mümkün olmadığından bahsetmiştik. Bu sebeple bir interface’i implemente edebilmek adına örneklerimizde hep TInterfacedObject isimli sınıfı kullanmıştık. Peki nedir bu TInterfacedObject ? Bir de ona yakından bakalım;

  TInterfacedObject = class(TObject, IInterface)
  protected
    FRefCount: Integer;
    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  public
    procedure AfterConstruction; override;
    procedure BeforeDestruction; override;
    class function NewInstance: TObject; override;
    property RefCount: Integer read FRefCount;
  end;

Gördüğünüz gibi TInterfacedObject sınıfı interface’lerin ata sınıfı olan IInterface arabirimini implemente etmiş durumda. Biz bundan sonraki örneklerimizde herhangi bir interface’i implemente ederken TInterfacedObject sınıfını kullanmaya devam edeceğiz. Ancak siz başka bir sınıftan miras almak istiyorsanız, IInterface’in içinde tanımlı olan 3 metodu da implemente etmeniz gerektiğini lütfen unutmayın.

Peki ne işe yarıyor bu 3 ayrı metod ? Bir kaç paragraf önce interface’lerin en önemli özelliklerinden bir tanesinin Referans Sayma Mekanizması olduğundan bahsetmiştik. İşte bu mekanizma bizim için son derece kullanışlı ve faydalı olacak. Delphi’de bütün interface’ler referans sayımlıdır. Kısaca referans sayımı; hafızadaki bir bellek bölgesine işaret eden herhangi bir nesneye kaç işaretçinin referansı olduğunu tutar. Hemen kısa bir örnek vererek izah etmeye gayret edelim:

type
  ITest = interface
  end;

  TTest = class(TInterfacedObject, ITest)
  public
    destructor Destroy; override;
  end;

var
  Test : ITest;

implementation

destructor TTest.Destroy;
begin
  ShowMessage('Nesne yok edilecek.!');
  inherited Destroy;
end;
..
..
var
   I1, I2, I3 : ITest;
   iRefCount : Integer;
begin
  Test := TTest.Create;
  iRefCount := TTest(Test).RefCount; // Referans = 1

  I1 := Test;
  iRefCount := TTest(Test).RefCount; // // Referans = 2

  I2 := Test;
  iRefCount := TTest(Test).RefCount; // Referans = 3

  I3 := Test;
  iRefCount := TTest(Test).RefCount; // Referans = 4

  I1 := nil;
  iRefCount := TTest(Test).RefCount; // Referans = 3

  I2 := nil;
  iRefCount := TTest(Test).RefCount; // Referans = 2

  I3 := nil;
  iRefCount := TTest(Test).RefCount; // Referans = 1
end;

Örneğimiz de ITest isimli herhangi bir metoda sahip olmayan bir interface ve o interface’i implemente etmiş bir basit sınıfımız var. Test değişkenimizin ve I1, I2, I3 değişkenlerimizin interface türünde olduğuna dikkat ediniz. Test := TTest.Create satırının işletilmesi hemen IInterface arabiriminin içinde tanımlı olan ve TInterfacedObject’de yeniden tanımlanan _AddRef isimli metoda dallanılmasını sağlar. Aynı şekilde I1 := Test; ataması, _AddRef metodunun yeniden çağırılmasına, dolayısı ile Test değişkeninin referans değerini 1 arttırmasına neden olur. TInterfacedObject sınıfının _Addref, _Release ve QueryInterface metodlarını nasıl uyguladığına biraz daha yakinen bakalım:

function TInterfacedObject.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
  if GetInterface(IID, Obj) then
    Result := 0
  else
    Result := E_NOINTERFACE;
end;

function TInterfacedObject._AddRef: Integer;
begin
  Result := InterlockedIncrement(FRefCount);
end;

function TInterfacedObject._Release: Integer;
begin
  Result := InterlockedDecrement(FRefCount);
  if Result = 0 then
    Destroy;
end;

Gördüğünüz gibi TInterfacedObject sınıfının _AddRef metodunda FRefCount isimli değişken Thread güvenlikli olarak(InterlockedIncrement) 1 arttırılıyor. _Release metodunda ise Thread güvenlikli olarak(InterlockedDecrement) 1 azaltılıyor. FRefCount değerinin 0′a düşmesi ilgili nesneye herhangi bir referans kalmaması anlamına geldiği için otomatikman Destroy metodu çağrılıyor.

Yukarıdaki örneğimizde Test : ITest tanımı global alanda yapıldığı için Destroy metodu çağrılmayacaktır. Ancak bu tanım, lokal olarak yapılsa idi ilgili procedure’den çıkıldığında otomatikman referans 1 azaltılacağından Destroy metodu çağrılabilecek ve nesnemiz yok edilecekti.! Bir interface değişkenine nil atamasının yapılması, yada o değişkenin kullanıldığı kod bloğundan çıkılması(scope’un dışına çıkılması) ilgili interface referansını 1 azaltan _Release çağrısına neden olur. Bu sayede gerçek sınıflarınıza interface değişkenlerle ulaşmanız, bellek yönetimini otomatik yapmanız anlamını taşır. Yine yukarıdaki örneğimiz için konuşacak olursak, lokal olarak tanımlanmış I1, I2 ve I3 değişkenlerine nil atamasının yapılmadığı düşünülürse, procedure’den çıkıldığında her bir değişken için otomatikman nil ataması yapılacak ve referanslar yine düzgün bir şekilde azaltılabilecektir.

Tüm bu yazdıklarımızdan sonra Interface’lerin referans sayma mekanizmasının memory leak’ler hususunda bizlere yardımcı olabildiğini görebiliyoruz. Aynı zamanda Interface’ler dilde native olarak bulunmayan multiple inheritance hususunda da bizlere yardımcı olabilmekteydi. Yukarıda tanımını verdiğimiz IInterface arabiriminin QueryInterface adlı metoduna şu ana dek hiç değinmedik. QueryInterface metodu bir nesnenin belirtilen bir interface’i implemente edip etmediğini sorgulamak için kullanılır. Örneğimizde kullandığımız gibi bazen interface referanslarımızdan nesne referanslarına dönüşüm yapmak isteriz. Bunun için ya casting uygularız yada as operatörünü kullanırız. Her iki durumda da TInterfacedObject sınıfının QueryInterface metoduna dallanılır.

Görüldüğü gibi aslında interface’ler ve abstract sınıflar birbirlerine benzer özelliklere sahip. Abstract sınıfların kalıtımdan yararlanmak, erişim belirleyicilerini kullanabilmek, değişken tanımlamalarına sahip olmak gibi özellikleri olmasına rağmen; Interface’ler de tüm bu özelliklere haiz olmamalarına rağmen multiple inheritance’a imkan sağlamak ve referans sayımı metodunun uygulanması sebebi ile otomatik yok etme mekanizmasının güzelliklerini bizlere sunabilmesi adına önemli bir kullanım alanına sahiptir.

Herhangi bir interface’i implemente etmiş olan bir sınıfa bir interface değişkeni vasıtası ile ulaşıyorsanız, o sınıfın yok edilmesi ile ilgilenmenize gerek kalmaz. Delphi sizler için bunu mükemmel bir şekilde yapabilir. Interface’ler ile ilgili konuşulacak daha başka hususlar da olabilir, ancak bu hususları anlatmak yerine sizlerin araştırmalarına ve testlerine bırakmak öğrenme yolunda faydalı bir adım olabilir.

Interface’lerle ilgili kısıtlı miktardaki bilgimi sizlerle paylaştıktan sonra, bir sonraki adımımız Operator Overloading ve ardından da Delphi ortamında istisnasız her sınıfı otomatikman yok edebilme becerisine sahip olacak bir tasarımı sizinle paylaşmak olacaktır.

Saygılar, sevgiler..

Ancak, sizlerden ricam bu makalede ilerlemeden önce Threading ile ilgili yazılmış olan diğer makaleleride okumanızdır. İlgili makalelere aşağıdaki linklerden erişebilirsiniz:

Nedir bu Thread’lerden çektiğimiz..!
Derinlemesine Threading..(1)
Derinlemesine Threading..(2)

Şimdi tüm bu makaleleri okuduğunuzu ve threading hakkında fikriniz olduğunu varsayarak, bir thread’i neden durdurmak isteyebileceğimizi ve karşımıza ne gibi sorunların çıkabileceğini biraz izah etmeye çalışalım. Bildiğiniz gibi thread’leri genellikle paralel programlama yapabilmek, iş yükünü dağıtabilmek, ana uygulamamızın kilitlenmesine mani olabilmek adına kullanırız. Ve bazen, thread’lerimizin içindeki kodlar uzun süreli ve hatta kullanıcı ile interaktif çalışıyor da olabilir.

Bazı durumlarda, yazdığımız thread’lerin içinde çalışan kod bloklarını sonlandırmak isteriz. Buna sanırım en güzel örnek, veritabanına bağlanıp büyük bir sonuç seti çekmeye çalıştığımız zamanlarda programımızın kullanıcısının isteği ile rapor alımını durdurmak verilebilir.

Pek çok programcı bu gibi durumlarda, çalışan thread’ini durdurabilmek için TThread sınıfının Terminated özelliğini kontrol eder. Terminated’in true olması durumunda thread çalışma kodundan çıkılmasını sağlar. Buna küçük bir örnek verebiliriz;

procedure TMyThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
     //...
     //...
  end;
end;

Yukarıdaki örnek, sıklıkla kullanılan çok genel bir örnektir. Malumunuz olduğu üzere; TThread sınıfının Terminate metodu bir thread’i durdurma işini yapmaz. Terminate metodu; Terminated isimli property’nin True olarak set edilmesini sağlar. Programımız içerisinde herhangi bir yerde TThread sınıfının Terminate metodunun çağrılması yukarıdaki kod örneği için ilgili thread’in sonlanması anlamını taşır.

Buraya kadar anlattıklarımızda bir sıkıntı ve bu makaleye hayat verecek bir neden de yok gibi görünüyor. Ancak; bizler her zaman thread’lerimiz içinde yukarıdaki kısa kod örneğinde olduğu gibi Terminated property’sinden istifade edemeyiz. Bu hususta da kısa bir örnek verip devam etmek sanırım daha açıklayıcı olacaktır:

procedure TMyThread.Execute;
begin
  inherited;

  with TADOStoredProc.Create(nil) do
  begin
    Connection := myThreadSpecificConnection;
    ProcedureName := 'sp_Stok_Hareket_List';
    Parameters.Refresh;
    Open; // Tüm stokların çekildiğini ve stok hareket tablosunda 10 milyon kayıt olduğunu düşünelim.

    //...
    //...
  end;
end;

Yukarıdaki örneğimiz; gerçek hayatta sıklıkla kullandığımız bir yapıya işaret ediyor. Örneğimizde; bir thread içinden Stok Hareket Raporu almaya çalışıyoruz. Ve Stok Hareket tablomuzdaki kayıt sayısının da 10 milyon olduğunu varsaydık. Bu gibi bir durumda; Open çağrısı en iyi ihtimalle onlarca dakika sürecektir. İşte tam bu noktada, programınızı kullanan kullanıcının; raporun alınmasının uzun sürmesinden mütevellit işlemden sıkılması ve iptal etmesi isteği hasıl olursa ne yapabiliriz ?

Bütün iş yükünü oluşturan kod TADOStoredProc’un Open metodunun içinde olduğu için; Terminated vb. kontrolleri kullanma imkanına sahip değiliz. Bu gibi zamanlarda, karşımıza bu makaleye konu olacak derin hususlar devreye girecektir.

Bir thread’i sonlandırabilmek için işletim sistemi API’lerinde bizlere sunulan bir kaç seçenek vardır. Bunlar; TerminateThread ve ExitThread API’leridir. Bu API’lerin ne işe yaradıklarını anlatmadan önce her zamanki gibi tanımlarına bir göz gezdirelim:

  VOID ExitThread(
    DWORD dwExitCode 	// exit code for this thread
   );

  BOOL TerminateThread(
    HANDLE hThread,	// handle to the thread
    DWORD dwExitCode 	// exit code for the thread
   );

ve Delphi tanımlarımız:

  procedure ExitThread(dwExitCode: DWORD);
  function TerminateThread(hThread: THandle; dwExitCode: DWORD): BOOL;

ExitThread API’si o anda çalışan uygulamanın içindeki thread’lerin hangisinde çağırılıyor ise o thread’den çıkmak için kullanılır. Yukarıdaki örneğimizde; TMyThread sınıfının Execute metodunda Open’dan sonra ExitThread API’sini kullanmak yine bizim istediğimiz neticeyi vermeyecektir.

ExitThread API’sini uygulamamızın main thread’inde çağırmak demek uygulamamızın kapanması anlamına geleceğinden diğer API’mize bakmak durumunda olacağız. TerminateThread ise kendisine geçilen bir thread handle vasıtası ile ilgili thread’i sonlandırabilme yeteneğine sahiptir.

Bizim istediğimiz işi TerminateThread API’si yapabildiğine göre o halde bu makaleye ne gerek vardı diye düşünüyor olabilirsiniz ?

Elbette bunun çok yerinde nedenleri var. TerminateThread API’sinin kullanımı son derece tehlikelidir. Bir thread içinde senkronizasyon nesneleri kullanıyorsanız(Critical Section, Event, Semaphore, Mutex vb.) TerminateThread çağrısından sonra thread’inizin sonlandırılma kodları çağırılamayacağı için, ilgili senkronizasyon nesneleriniz sürekli açık yada kapalı konumlarında kalabilir. Bu da, bu senkronizasyon nesnelerini ortak kullanan diğer thread’leriniz için son derece büyük bir sorun teşkil edebilir. Aynı zamanda; TerminateThread ile yapacağınız sonlandırmalar; thread içinde oluşturduğunuz nesnelerinizin Free edilememesi, ayırdığınız hafıza bloklarının işletim sistemine iade edilememesi gibi ciddi sorunlara neden olabilir.

İşte bu sebeplerden ötürü, gerçekten çok ihtiyacınız yoksa TerminateThread API’sinin kullanılması tavsiye edilmez.! Peki bu durumda, biz thread’lerimizi sonlandıramayacak mıyız ?

Evet, sonlandırabileceğiz. Ancak, biraz karmaşık bir yöntem kullanmamız gerekecek. Bu yöntemi izaha geçmeden önce; diğer threading mekanizmalarında gördüklerinizi yeniden anımsamanız gerekecek. Hatırlayacağınız üzere, işletim sistemi aynı anda sadece bir tane işlem yapabilmektedir. Thread’lerin birbirleri arasındaki geçişlerinin 20 ms. olduğunu ve bu geçişler için Round Robin denilen algoritmanın kullanıldığını sanırım anımsıyorsunuz.

Tam bu noktada; ilgili threading makalelerinde değinmediğimiz bir soru sormamız gerekiyor kendimize. İşletim sistemi thread’ler arasında geçişler yaparken; thread’lere has local değişkenlerin bilgilerini, o anda thread execute kodunun hangi satırında kaldığını, hangi nesnelerle işlem yaptığını ve o nesnelerin hafıza adreslerinin ne olduğunu nereden biliyor olabilir ?

Eğer işletim sistemi thread’lerle alakalı tüm bu bilgilere haiz olmasa idi, thread’ler arasında geçişi sağlayamaz; sağlasa da CPU son işlediği komutu bilemeyeceği için gerçek bir threading’den söz edilemezdi.

Sizlere bu hususu izah edebilmem için az da olsa assembly bilgisine haiz olmanız gerekmekte. Bildiğiniz gibi; tüm programlama dillerinde üretilen çalıştırılabilir dosyalar işlemci assembly kodlarına dönüştürülür ve öyle icra edilir. Olayın derinliklerinde CPU’nun sadece 0(Sıfır) ve 1(Bir) lerden anladığı da bir gerçekken, assembly kodları da makina kodlarına dönüştürülür.

Kabaca; CPU’nun çalışacak kodları işletebilmesi için çeşitli register‘lara ihtiyacı vardır. Hemen hemen hepimiz az da olsa bu register’lara aşinayızdır. acx, ecx, ah, al, eip, cs, ds gibi registerları en azından görmüş yada bunlar hakkında bir genel kültüre sahibizdir.

Delphi programlama ortamında CPU Editoru aşağıdaki gibi görünür. Sizlerinde aşağıdaki resimde gözlemleyebileceğiniz gibi; pek çok register ve assembly kodları görünmekte. Şimdilik sadece EIP register‘ının içindeki değerin(0045187C) sol taraftaki Memo1.Lines.Add kod satırındaki numara ile aynı olduğunu farketmenizi rica ediyorum.

Örneğimizde ki 0045187C bir hafıza adresidir ve o anda CPU tarafından işletilen kodun nerede olduğunu bulmaya yarar. CPU bu değere her zaman EIP registerı içinden erişir. Satır satır işletilen her kod’un hafıza edresi EIP registerı içerisinde tutulur.

Tüm bu bilgileri vermemizin nedeni; işletim sisteminin thread geçişlerinde yukarıda bir kısmını gözlemleyebildiğiniz pek çok CPU register’ını bir yere saklıyor olmasından ve thread’e geri dönüşte ilgili register’ların içeriklerini sakladığı yerden yeniden okuyup eski haline almasından ötürüdür. İşletim sistemi thread geçişlerinde ihtiyacı olan tüm bilgileri _CONTEXT isimli bir record’un içine doldurur ve bir yerlerde bu record’u saklar. Thread’e geri dönmesi gerektiğinde sakladığı yerdeki bilgileri _CONTEXT recordunun içerisine geri yükler ve bu sayede CPU kaldığı noktadan kodları işletmeye devam edebilir.

İzahatlarımızda daha fazla ilerlemeden evvel, bu recordun yapısını sizlerle paylaşayım:

  _CONTEXT = record
  {$EXTERNALSYM _CONTEXT}

  { The flags values within this flag control the contents of
    a CONTEXT record.

    If the context record is used as an input parameter, then
    for each portion of the context record controlled by a flag
    whose value is set, it is assumed that that portion of the
    context record contains valid context. If the context record
    is being used to modify a threads context, then only that
    portion of the threads context will be modified.

    If the context record is used as an IN OUT parameter to capture
    the context of a thread, then only those portions of the thread's
    context corresponding to set flags will be returned.

    The context record is never used as an OUT only parameter. }

    ContextFlags: DWORD;

  { This section is specified/returned if CONTEXT_DEBUG_REGISTERS is
    set in ContextFlags.  Note that CONTEXT_DEBUG_REGISTERS is NOT
    included in CONTEXT_FULL. }

    Dr0: DWORD;
    Dr1: DWORD;
    Dr2: DWORD;
    Dr3: DWORD;
    Dr6: DWORD;
    Dr7: DWORD;

  { This section is specified/returned if the
    ContextFlags word contians the flag CONTEXT_FLOATING_POINT. }

    FloatSave: TFloatingSaveArea;

  { This section is specified/returned if the
    ContextFlags word contians the flag CONTEXT_SEGMENTS. }

    SegGs: DWORD;
    SegFs: DWORD;
    SegEs: DWORD;
    SegDs: DWORD;

  { This section is specified/returned if the
    ContextFlags word contians the flag CONTEXT_INTEGER. }

    Edi: DWORD;
    Esi: DWORD;
    Ebx: DWORD;
    Edx: DWORD;
    Ecx: DWORD;
    Eax: DWORD;

  { This section is specified/returned if the
    ContextFlags word contians the flag CONTEXT_CONTROL. }

    Ebp: DWORD;
    Eip: DWORD;
    SegCs: DWORD;
    EFlags: DWORD;
    Esp: DWORD;
    SegSs: DWORD;
  end;

Gördüğünüz gibi pek çok üyesi var. Ancak hemen endişeye kapılmayın. Bizler sadece EIP üyesi ile ilgileniyor olacağız. Record’un diğer üyeleri şu an için bizim konumuz dışında olması münasebeti ile bu üyeler hakkındaki kısıtlı bilgilerimi sizlerle paylaşmıyorum.

Tüm bu açıklamalardan sonra; bir thread’i nasıl sonlandırabileceğimiz hakkında hâla kafanızda soru işaretleri olduğunu hissediyorum. Biz bunun için; genellikle Reverse Engineering konularından birisinin kapsamına gireceğiz. Yani bir thread’in o anda işletmekte olduğu kodun adresini bir başka metodun adresi ile değiştireceğiz. Yapacağımız işin sırrı da tam olarak bu noktada.

Kısaca ve kabaca ifade etmek gerekir ise; thread’in zaman alan bir işlemi yürütüyor olduğu sırada EIP registeri içindeki CPU’nun işlettiği kodun adresini bir başka kod adresi ile değiştireceğiz. Böylece CPU’yu kandırmış olacağız ve thread’in kodları içine bir nevi code injection yapmış olacağız. Bu senaryoyu aşağıdaki pseudo kod ile örnekleyebiliriz:

procedure TMyThread.Execute;
begin
  inherited;

  with TADOStoredProc.Create(nil) do
  begin
    Connection := myThreadSpecificConnection;
    ProcedureName := 'sp_Stok_Hareket_List';
    Parameters.Refresh;
    Open; // Tüm stokların çekildiğini ve stok hareket tablosunda 10 milyon kayıt olduğunu düşünelim.

    //...
    //...
  end;
end;

procedure TForm1.Button1Click(Sender : TObject);
begin
  Change_EIP_Register(myThread, @MyProcedure);
end;

procedure MyProcedure;
begin
  raise Exception.Create('Thread dursun artık..!');
end;

procedure Change_EIP_Register(Thread : TThread; ProcedureAddr : Pointer);
begin
  // Thread'i durdur(Suspend)
  // Thread'in Context record bilgilerini al.
  // Context recordunun içindeki EIP üyesinin değerini ProcedureAddr ile değiştir.
  // Yeni context recordunu thread'in eski context'i ile değiştir.
  // Thread'i yeniden çalıştır(Resume)
end;

Yukarıdaki pseudo kodda görebileceğiniz gibi öncelikle thread’imizi durdurmamız icap ediyor. Context bilgilerinin alınabilmesi için bu şart. Ardından Context record’u içindeki EIP registerımızın içinde bulunan o anda çalışmakta olan kod satırının adresini; yeni tanımladığımız MyProcedure ile değiştiriyor ve thread context’imizi güncelleyip thread’imizi yeniden çalıştırıyoruz. Bu aşamada; CPU direkt olarak MyProcedure metodunun adresini EIP registerından okur ve ilgili kodları çalıştırmaya başlar. MyProcedure metodunun içinde bir exception oluşturduğumuz içinde thread’imiz anında sonlanacaktır ve bu vesile ile thread sonlandırma kodlarımız da gerektiği gibi işletilebilecektir(OnTerminate).

Şimdi sıra bize gereken API’lerin tanımlarına geldi:

  DWORD SuspendThread(
    HANDLE hThread 	// handle to the thread
   );

  BOOL GetThreadContext(
    HANDLE hThread,	// handle of thread with context
    LPCONTEXT lpContext 	// address of context structure
   );

  BOOL SetThreadContext(
    HANDLE hThread,	// handle of thread with context
    CONST CONTEXT *lpContext 	// address of context structure
   );

  DWORD ResumeThread(
    HANDLE hThread 	// identifies thread to restart
   );

ve Delphi tanımları:

  function SuspendThread(hThread: THandle): DWORD;
  function GetThreadContext(hThread: THandle; var lpContext: TContext): BOOL;
  function SetThreadContext(hThread: THandle; const lpContext: TContext): BOOL;
  function ResumeThread(hThread: THandle): DWORD;

Tanımlarımızı da sizlerle paylaştığımıza göre; artık örnek kodumuzu yazabiliriz:

var
  mThread : TMyThread;

implementatiton

constructor TMyThread.Create;
begin
  inherited Create(true);
  FreeOnTerminate := true;
end;

procedure TMyThread.Execute;
begin
  inherited;

  with TADOStoredProc.Create(nil) do
  begin
    Connection := myThreadSpecificConnection;
    ProcedureName := 'sp_Stok_Hareket_List';
    Parameters.Refresh;
    Open; // Tüm stokların çekildiğini ve stok hareket tablosunda 10 milyon kayıt olduğunu düşünelim.

    //...
    //...
  end;
end;

procedure TForm1.ThreadTerminated(Sender : TObject);
begin
  Memo1.Lines.Add('Bitiş Zamanı:' + TimeToStr(Time)); // Memo1 TMemo türündedir.
end;

procedure TForm1.StartThreadClick(Sender : TObject); // StartThread TButton türündedir.
begin
  Memo1.Lines.Add('Başlangıç Zamanı:' + TimeToStr(Time)); // Memo1 TMemo türündedir.

  mThread := TMyThread.Create;
  mThread.OnTerminate := ThreadTerminated;
  mThread.Resume;
end;

procedure StopTheThread;
begin
  raise Exception.Create('Thread terminated by using Context Record EIP Register..');
end;

procedure TForm1.StopThreadClick(Sender : TObject); // StopThread TButton türündedir.
var
  ctx : _CONTEXT;
  ThreadHandle : THandle;
begin
  ThreadHandle := mThread.Handle;

  SuspendThread(ThreadHandle); // Thread'i durdur..
  ctx.ContextFlags := CONTEXT_FULL; // Tüm Context bilgisini istedik.
  GetThreadContext(ThreadHandle, ctx);

  ctx.Eip := Cardinal(@StopTheThread);

  SetThreadContext(ThreadHandle, ctx);
  ResumeThread(ThreadHandle); // Thread'i başlat..
end;

Yukarıdaki kodu çalıştırıp denemelerinizi yaptığınızda uzun süren thread’inizin sonlandırıldığını ve sonlandırılma kodlarının da düzgün bir şekilde çalışabildiğini gözlemleyebilirsiniz. Bu yöntem, biraz karmaşık ve uzun olsa da; thread sonlandırmanız gerektiğinde kullanmanız icap eden en önemli yöntemdir. TerminateThread API’sinin dezavantajlarının hiçbirisine sahip olmaması programlarınızın daha güvenli çalışabilmesi adına büyük bir avantajdır.

Elbette bu yöntem kötüye de kullanılabilir, EIP register’ının içindeki değer değiştirilmeden önce bir başka değişkende saklanırsa ve ardından değiştirilir ve thread yeniden çalıştırılırsa; buna mukabil eski EIP değeri yeniden context’e atanırsa bir thread’in içine code injection yapmış olursunuz. Buna da küçük bir örnek vererek makalemi neticelendirmek istiyorum müsaadeniz ile:

procedure StopTheThread;
begin
  Memo1.Lines.Add('Thread durduruldu.!');
end;

procedure TForm1.StopThreadClick(Sender : TObject); // StopThread TButton türündedir.
var
  ctx : _CONTEXT;
  ThreadHandle : THandle;
  OldEIP : Cardinal;
begin
  ThreadHandle := mThread.Handle;

  SuspendThread(ThreadHandle);
  ctx.ContextFlags := CONTEXT_FULL; // Tüm Context bilgisini istedik.
  GetThreadContext(ThreadHandle, ctx);
  OldEIP := ctx.EIP;
  ctx.Eip := Cardinal(@StopTheThread);

  SetThreadContext(ThreadHandle, ctx);
  ResumeThread(ThreadHandle);

  Sleep(5000); // 5 sn. yeni kodumuzun çalışmasını bekleyelim ve eski çalışma şekline geri dönelim.

  SuspendThread(ThreadHandle);
  ctx.ContextFlags := CONTEXT_FULL; // Tüm Context bilgisini istedik.
  GetThreadContext(ThreadHandle, ctx);
  ctx.Eip := OldEIP;

  SetThreadContext(ThreadHandle, ctx);
  ResumeThread(ThreadHandle);
end;

Kötü amaçlarla kullanmamanız dileği ile

Saygılar, sevgiler..

Aşağıdaki 2 fonksiyon size stringler arasındaki benzerlik oranlarını vermekte en benzer olanların sonuçları en küçük olanlar çıkacaktır. Yani fark arttıkça dönen sayı artmakta bunu unutmayın.

CREATE FUNCTION edit_distance(@s1 nvarchar(3999), @s2 nvarchar(3999))
RETURNS int
AS
BEGIN
  DECLARE
     @s1_len int,
     @s2_len int,
     @i int,
     @j int,
     @s1_char nchar,
     @c int,
     @c_temp int,
     @cv0 varbinary(8000),
     @cv1 varbinary(8000)

  SELECT
    @s1_len = LEN(@s1),
    @s2_len = LEN(@s2),
    @cv1 = 0x0000,
    @j = 1,
    @i = 1,
    @c = 0

   WHILE @j <= @s2_len
     SELECT
       @cv1 = @cv1 + CAST(@j AS binary(2)),
       @j = @j + 1

  WHILE @i <= @s1_len
  BEGIN
    SELECT
      @s1_char = SUBSTRING(@s1, @i, 1),
      @c = @i,
      @cv0 = CAST(@i AS binary(2)),
      @j = 1

    WHILE @j <= @s2_len
    BEGIN
      SET @c = @c + 1
      SET @c_temp = CAST(SUBSTRING(@cv1, @j+@j-1, 2) AS int) +
        CASE
          WHEN @s1_char = SUBSTRING(@s2, @j, 1) THEN 0 ELSE 1
        END

      IF @c > @c_temp SET @c = @c_temp
      SET @c_temp = CAST(SUBSTRING(@cv1, @j+@j+1, 2) AS int)+1

      IF @c > @c_temp SET @c = @c_temp
      SELECT @cv0 = @cv0 + CAST(@c AS binary(2)), @j = @j + 1
    END

  SELECT @cv1 = @cv0, @i = @i + 1
  END
RETURN @c
END

LEVINSTEIN ALGORITMASI

CREATE FUNCTION dbo.fn_LevenshteinDistance
(
  @Str1 VARCHAR(3999)
, @Str2 VARCHAR(3999)
)
RETURNS INT
AS
BEGIN
/*
#
SELECT dbo.fn_LevenshteinDistance('test', 'test')
#
SELECT dbo.fn_LevenshteinDistance('tesot', 'test')
#
SELECT dbo.fn_LevenshteinDistance('testing1', 'tes_ing')
#
*/

  DECLARE @m INT, @n INT
  DECLARE @editMatrix TABLE(pk1 INT, pk2 INT, v INT, PRIMARY KEY (pk1, pk2))
  DECLARE @i INT, @j INT, @cost INT
  DECLARE @str1_i CHAR, @str2_j CHAR

  SET @n = DATALENGTH(ISNULL(@Str1, ''))
  SET @m = DATALENGTH(ISNULL(@Str2, ''))

  IF @n = 0 OR @m = 0 RETURN 0

  SET @i = 0
  WHILE @i <= @n
  BEGIN
    SET @j = 0
    WHILE @j <= @m
    BEGIN
      IF @j = 0
        INSERT INTO @editMatrix VALUES(@i, 0, @i)
      ELSE IF @i = 0
        INSERT INTO @editMatrix VALUES(0, @j, @j)
      ELSE
        INSERT INTO @editMatrix VALUES(@i, @j, 0)

      SET @j = @j + 1
    END

    SET @i = @i + 1
  END

  SET @i = 1
  WHILE @i <= @n
  BEGIN
    SET @str1_i = SUBSTRING(@Str1, @i, 1)

    SET @j = 1
    WHILE @j <= @m
    BEGIN
      SET @str2_j = SUBSTRING(@Str2, @j, 1)

      IF @str1_i = @str2_j
        SET @cost = 0
      ELSE
        SET @cost = 1

      UPDATE em
      SET v = (
        SELECT MIN(ret) AS MIN_ret
        FROM (
          SELECT v + 1 AS ret
          FROM @editMatrix
          WHERE pk1 = @i - 1 AND pk2 = @j     

          UNION ALL

          SELECT v + 1 AS ret
          FROM @editMatrix
          WHERE pk1 = @i AND pk2 = @j - 1 

         UNION ALL

         SELECT v + @cost AS ret
         FROM @editMatrix
         WHERE pk1 = @i - 1 AND pk2 = @j - 1
       ) AS x
    )
      FROM @editMatrix AS em
      WHERE pk1 = @i AND pk2 = @j

      SET @j = @j + 1
    END

    SET @i = @i + 1
  END

 RETURN (SELECT ISNULL(v, -1) FROM @editMatrix WHERE pk1 = @n AND pk2 = @m)
END

Full Text Search servisi ile SQL Server”da karakter bazlı alanlarda arama yapılarak daha verimli arama sonuçları elde edilebilir, ancak arama yapılacak olan alanlar üzerinde ilk olarak Full-Text Index”ler tanımlanmalıdır. Full Text Index”ler belirtilen alanın verisini fiziksel olarak belirtilen alana indeksleyerek bu alan içerisinde arama yapılmasını kolaylaştırır. Full Text Index tanımlamak için indeksin tanımlanacak olduğu tablo üzerine sağ tıklayarak Full Text Index seçeneği üzerinden Define Full Text Index seçeneği seçilmelidir. Full-Text Index tanımlarken bu Full-Text Indexler”in gruplanacağı yeni bir Full-Text Catalog tanımlanacağı gibi var olan bir kataloga da eklenmesi sağlanabilir. Full-Text Index tanımlanırken dikkat edilmesi gereken bir nokta da indeksin tanımlanacak olduğu tabloda en azından bir tane UniqueKey tanımlanmış olması gerekliliğidir. Tabi bu ayarı yapabilmek için DataBase”de Full Text Indexing özelliğinin aktif olarak ayarlanmış olması gerekmektedir. Eğer üzerinde arama yapılmak istenilen DataBase”in Full-Text Indexing özelliği aktif değilse DataBase”in özelliklerinden Files bölümünde bulunan CheckBox seçili hale getirilerek aktif yapılabilir. Full-Text Index”ler char, varchar, text, ntext, nchar ve nvarchar veri tipinde tanımlanmış olan alanlar üzerinde tanımlanabilir ve Full Text Search servisi bu alanlarla kullanılabilir.
Arama yapılacak olan sütun ya da sütunlar üzerinde Full-Text Search servisi kullanılarak arama yapmak için kullanılabilecek bir kaç farklı SQL sözcüğü vardır bu yazımda bunlardan CONTAINS ve FREETEXT sözcükleri üzerinde örnekleme yapıyor olacağım.

CONTAINS
Contains sözcüğü ile hedef alan içerisinde arama yapılacak olan sözcüklerin içinde geçtiği kayıtlar ve bu sözcüğe yakın olan kayıtlar listeleniyor olacaktır. Bu alanda örnek vermek gerekirse drive sözcüğünü ele aldığımızda sorgu sonucunda drive, drove, drives, driving ve diriven gibi sözcükleri içeren kayıtlarda sorgu sonucunda yer alıyor olacaktır. Contains sözcüğünün kullanımını aşağıda yer almaktadır.

SELECT Description
FROM Production.ProductDescription
WHERE CONTAINS ( *, " "For true" " )

Contains sözcüğü kullanılırken ilk olarak * işareti ile tablo üzerinde tanımlı olan tüm Full-Text Index”lerde arama yapılacağı belirtiliyor, bu alanda istenilirse indeks tanımlı olan sütunlardan istenilenlerde verilebilirdi. Diğer alanda ise aranacak sözcük belirtilerek belirtilen kayıt ve belirtilen kayda yakın kayıtlar getiriliyor. Contains sözcüğü ile birlikte WHERE ile kullanmaya alışık olduğumuz OR ve AND sözcükleri de kullanılabilir. Aşağıdaki sorgu çalıştırıldığında içerisinde “Aluminum alloy cups” ya da “For true” sözcükleri veya bunlarla benzer söz dizimine sahip olan sözcükleri içeren kayıtlar listeleniyor olacaktır.

SELECT Description
FROM Production.ProductDescription
WHERE CONTAINS ( *, ""Aluminum alloy cups" OR "For true" " )

FREETEXT
Freetext sözcüğü ile hedef alan içerisinde belirtilen ifade ve kelimeler çözümlenerek onlara benzer kayıtlar listeleniyor. Bu alanda örnek vermek gerekirse “Microsoft Türkiye Ofisi”ndeki seminer oldukça güzeldi ve faydalı bilgiler içeriyordu.” cümlesini ele alalım. Bu alanda arama yapılırken tanımlanacak olan kelimeler Microsoft, Türkiye, Ofis, Seminer, Güzel, Faydalı, Bilgi şeklinde olacaktır. Tanımlanan ifadeler ise Microsoft Türkiye Ofisi, Faydalı bilgi şeklinde olacaktır. Freetext sözcüğü de aşağıdaki gibi kullanılabilir.

Birkaç basit örnek;

SELECT Description
FROM Production.ProductDescription
WHERE FREETEXT( description,""For true trail addicts."")

Kodlara dikkat edilirse bu kodlarda sadece description sütunu üzerinde tanımlı olan index üzerinde arama yapılacaktır.

USE AdventureWorks;
GO
SELECT Title
FROM Production.Document
WHERE FREETEXT (Document, 'vital safety components' );
GO

USE Northwind;
GO
SELECT   K.RANK, CompanyName, ContactName, Address
FROM      Customers AS C
         INNER JOIN
         CONTAINSTABLE(Customers,Address, 'ISABOUT ("des*",
            Rue WEIGHT(0.5),
            Bouchers WEIGHT(0.9))', 3) AS K
         ON C.CustomerID = K.[KEY];
GO

USE AdventureWorks;
GO
DECLARE @SearchWord varchar(30)
SET @SearchWord ='performance'
SELECT Description
FROM Production.ProductDescription
WHERE FREETEXT(Description, @SearchWord);

Use AdventureWorks;
GO
SELECT Name, Color FROM Production.Product
WHERE CONTAINS((Name, Color), 'Red');

KONUYLA ALAKALI FAYDALI LİNKLER
Querying SQL Server Using Full-Text Search
Limiting Ranked Result Sets (Full-Text Search)
FREETEXT (Transact-SQL)

Overload ifadesi gecmisken asagidaki yaziya da goz atmanizi tavsiye ederim.
http://tr.delphipeak.com/2007/08/30/overload-metodlar.htm

Delphi 2010 ile birlikte genisletilmis bir RTTI (Run-Time Type Information) destegi bizi bekliyor. Tabi bicok seyde oldugu gibi bu ozelliginde bir iyi tarafi var bir de kotu tarafi. Kotu tarafi kodlarinizin decompile edilmesi eskiye nazaran biraz daha kolay olacak iyi tarafi ise calisma zamaninda nesneler hakkinda artik daha fazla bilgi edinebilecegiz ve bu da bize normalde yapilmasi mumkun olmayan ya da bircok taklalar atmamiza neden olacak isleri artik cok kolay bir sekilde yapabilmemizi saglayacak. Kotu tarafi ile ilgili olarak soyleyebilecegimiz iyi haber ise delphinin bu ozelliginin istege bagli olmasi. Yani istersek bu ozelligi kapatabiliyoruz.

{$RTTI EXPLICIT METHODS([]) FIELDS([]) PROPERTIES([])}

Bu ozellik sayesinde yapabileceklerimiz oldukca genis ama bir iki tane ornek vermek gerekirse en basitindan AOP (Aspect Oriented Programming ) uygulamak isterseniz bu cok basit bir sekilde yapabilirsiniz artik ya da tipini bilmediginiz bir degiskeni bir metoda gonul rahatligi ile gonderebilirsiniz. Tip cevrimleriyle ugrasmak yerine degiskenin tipini delphi calisma zamaninda kendi belirlesin.

Simdi bu degiskenin degerinin calisma zamaninda nasil belirlendigine soyle bir bakalim.

TValue adinda Record olarak tanimlanmis yeni bir yapimiz mevcut Delphi 2010 da. TValue kendisine gonderdigimiz degiskenin tipini calisma zamaninda belirleme gibi ozellikleri icerisinde barindiriyor.

function TValue.ToString: string;
begin
  if IsEmpty then
    Exit('(empty)'); // do not localize

  case FData.FTypeInfo^.Kind of
    tkUnknown: Result := '(unknown)'; // do not localize
    tkInteger: Result := IntToStr(AsInt64);
    tkChar: Result := string(AsType);
    tkEnumeration: Result := GetEnumName(FData.FTypeInfo, FData.FAsSLong);
    tkFloat:
      case GetTypeData(FData.FTypeInfo)^.FloatType of
        ftSingle: Result := FloatToStr(FData.FAsSingle);
        ftDouble: Result := FloatToStr(FData.FAsDouble);
        ftExtended: Result := FloatToStr(FData.FAsExtended);
        ftComp: Result := IntToStr(FData.FAsSInt64);
        ftCurr: Result := CurrToStr(FData.FAsCurr);
      end;
    tkString, tkLString, tkUString, tkWString: Result := AsType;
    tkSet: Result := SetToString(FData.FTypeInfo, FData.FAsSLong, True);
    tkClass:
      if FData.FAsObject = nil then
        Result := '(empty)' // do not localize
      else
        Result := Format('(%s @ %p)', [AsObject.ClassName, Pointer(AsObject)]);

    tkMethod: Result := Format('(method code=%p, data=%p)', [FData.FAsMethod.Code, FData.FAsMethod.Data]); // do not localize
    tkWChar: Result := AsType;
    tkVariant: Result := '(variant)'; // do not localize
    tkArray: Result := '(array)'; // do not localize
    tkRecord: Result := '(record)'; // do not localize
    tkPointer: Result := Format('(pointer @ %p)', [Pointer(FData.FAsSLong)]); // do not localize
    tkInterface: Result := Format('(interface @ %p)', [Pointer(FData.FHeapData)]); // do not localize
    tkInt64:
      with GetTypeData(FData.FTypeInfo)^ do
        if MinInt64Value > MaxInt64Value then
          Result := UIntToStr(FData.FAsUInt64)
        else
          Result := IntToStr(FData.FAsSInt64);
    tkDynArray: Result := '(dynamic array)'; // do not localize
    tkClassRef:
      if FData.FAsClass = nil then
        Result := '(empty)' // do not localize
      else
        Result := Format('(class ''%s'' @ %p)', [FData.FAsClass.ClassName, Pointer(FData.FAsClass)]); // do not localize
  end;
end;

Eger bir metod TValue tipinde bir parametre aliyorsa biz bu metoda string , integer , obje , tarih gibi bir cok degeri tip cevrimine gerek kalmadan gonderebiliyoruz artik ve gonderdigimiz parametrenin tipini TValue kendisi belirliyor, uygun olan sekilde geriye degerini donderiyor. Kucuk bir ornek yapalim.

  function DegerYaz(Value: TValue): string;
  begin
    Result := Value.ToString;
  end;

seklinde bir metodumuz olsun. Aldigi parametreye dikkat ederseniz TValue tipinde. Bu metoda gonderecegimiz her turlu veri tipi gecerlidir. ToString metodu ise bize gonderdigimiz veri tipine uygun olan string ifadeyi tespit edip geri donderecektir.

program Project2;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Classes,
  Rtti; // --> TValue recordunun tanimlandigi unit.

function DegerYaz(Value: TValue): string;
begin
  result := Value.ToString;
end;

var
  SL: TStringList;
  Obje: TObject;
  Dizi: array of string;
  tarih: TDate;

begin
  try
    tarih := now;
    SL := TStringList.Create;
    SL.Add('1');
    SL.Add('2');
    SL.Add('3');
    Obje := TObject.Create;
    SetLength(Dizi, 2);
    Dizi[0] := 'delphi';
    Dizi[0] := '2010';
    Dizi[0] := 'super';
    tarih := tarih + 1;
    writeln(DegerYaz('string ifade'));
    writeln(DegerYaz(1));
    writeln(DegerYaz(True));
    writeln(DegerYaz(SL));
    writeln(DegerYaz(Obje));
    writeln(DegerYaz(tarih));
    readln;
  except
    on E: Exception do
      writeln(E.ClassName, ': ', E.message);
  end;

end.

bu programin consola ciktisi ise su sekilde olacaktir.

string ifade
1
True
(TStringList @ 00A4DB00)
(TObject @ 00A30D30)
40036,9031108912)

Kod yazma aliskanligizi koklu bir sekilde degistirmeye aday olan TValue cok yakinda aramizda olacak

Hatırlayacağımız üzere, critical section’lar belirli bir kritik kod bloğuna aynı anda birden fazla thread’in girmesine müsaade etmiyordu. Mutex’ler ise critical section’lara son derece benzemelerine rağmen birden fazla uygulamanın(process) thread’lerinin de aynı kod bloklarına girişlerini senkronize ediyordu. Ardından temas ettiğimiz semaphore’ler ise biraz daha farklı bir yaklaşım ile kritik bir kod bloğuna bizim belirlediğimiz sayıda thread’in girmesini sağlıyordu.

Event mekanizmaları da yukarıda sayılan thread senkronizasyon mekanizmaları gibi çalışırlar. Ancak elbette kendine özgü tarafları da vardır. Programlarımızda hangi thread senkronizasyon mekanizmasını kullanacağımız tamamen ihtiyaçlarımız ile doğru orantılıdır. Birinin bir diğerine üstünlüğü gibi bir şey söz konusu değildir. Tüm bu bahsedilen mekanizmaların asıl amacı, işletim sistemindeki thread geçişlerinin 20 ms. olduğu bir ortamda veriye hatasız bir şekilde erişmek ve kullanabilmektir.

Event mekanizmaları, birden fazla thread’in ortaklaşa çalışması söz konusu olduğunda anlamlı olurlar. Bir thread’in bir diğer thread’i beklemesi gerektiğinde, kısaca bir ekip ruhunun gerektiği noktalarda bu mekanizma son derece kullanışlıdır. Eğer kodlarınızın bir ekip ruhu ile çalışması gerekiyor ise, aralarında bir imece söz konusu ise o halde bu mekanizmayı bilmeniz faydalı olacaktır.

Event mekanizmasını anlatabilmek adına, mübarek miraç kandili vesilesi ve ramazan ayının yaklaşıyor olması münasebeti ile Ramazan ayına has bir örnek tercih ettim. Bu örneğimiz; iftar saatine yakın bir zaman diliminde evimizde geçen olaylara ilişkin bir senaryoyu içeriyor.

Evde; anne, baba, çocuk ve bir misafirimiz var. Senaryomuz gereği; iftara yarım saat kala anne yemekleri ısıtmaya başlar. Yemeklerin ısınmasına başlanılması ile baba sofra kurma hazırlıklarına girişir. İftara 5 dk kala, evin küçük çocuğu pide almak üzere evden dışarı çıkar. Ezan’ın okunması ile tüm ev ahalisi iftarlarını açarlar.

Bu küçük ama ramazan ayında hemen hemen hepimizin yaşadığı senaryonun bilgisayara aktarılması sırasında thread’ler ve event senkronizasyon mekanizması kullanacağız. İftar saati gelene kadar tüm ev ahalisinin sohbet ettiğini yada televizyon seyrettiğini varsayıyoruz. İftar’a yarım saat kala anne thread bir event vasıtası ile tetikleniyor ve yemekleri ısıtmaya başlıyor. Ardından baba thread, anne thread tarafından sofrayı kurması için uyarılıyor. Anne ve baba thread’ler üstlerine düşen vazifeleri yaparlarken, diğer ev ahalisi hâla sohbet ve televizyon izleme ile iştigal ediyorlar.

İftara 5 dakika kala, çocuk thread’imiz evden pide almak üzere ayrılıyor. Misafirimiz bu arada televizyon izlemek ile meşgul. Çocuk pide almaktan gelince, baba sofrayı kurmuş, anne yemekleri ısıtmış durumda. Ve hep birlikte ezanın okunmasını bekliyorlar. Ezanın okunmasına müteakip; tüm ev ahalisi oruçlarını açıyorlar.

Senaryomuz hakkında özet bir bilgi verdikten sonra, event senkronizasyon mekanizmasında kullanılan metodların tanımlarına bir bakalım isterseniz;

HANDLE CreateEvent(
    LPSECURITY_ATTRIBUTES lpEventAttributes,
    BOOL bManualReset,
    BOOL bInitialState,
    LPCTSTR lpName
   );

HANDLE OpenEvent(
    DWORD dwDesiredAccess,
    BOOL bInheritHandle,
    LPCTSTR lpName
   );

BOOL SetEvent(
    HANDLE hEvent
   );

BOOL ResetEvent(
    HANDLE hEvent
   );

ve Delphi tanımlarımız:

function CreateEvent(lpEventAttributes: PSecurityAttributes;
  bManualReset, bInitialState: BOOL; lpName: PChar): THandle; stdcall;

function OpenEvent(dwDesiredAccess: DWORD; bInheritHandle: BOOL; lpName: PChar): THandle; stdcall;

function SetEvent(hEvent: THandle): BOOL; stdcall;

function ResetEvent(hEvent: THandle): BOOL; stdcall;

Tanımlarından gördüğünüz gibi daha önce anlattığımız senkronizasyon nesneleri ile bir farklılıkları görülmüyor. Hatırladığınız üzere senkronizasyon nesnelerini bir kapıya benzetmiştik. Kapının açık yada kapalı olması durumları gibi senkronizasyon nesneleri de açık yada kapalı durumlarına sahiptirler. CreateEvent API fonksiyonunun ikinci parametresi olan bManualReset kapının açılma kapanma işinin otomatik mi yoksa bize mi bırakılacağının kararını içeriyor. Bu parametreye true geçilmesi, SetEvent metodu ile açık duruma geçen kapının ResetEvent ile kapatılmasını bizim kontrol etmemiz gerektiğini ifade ediyor. Bu parametreye false geçilmesi durumunda, kapının açık olduğunu görüp ilgili kod bloğunu geçen thread kapıyı ardından otomatikman kapatacak ve başka thread’ler kapının önünde beklemeye devam edeceklerdir. Biz örneğimizde bu parametrenin her iki durumunuda kullanacağız.

Tanımları verdiğimize ve bu tanımların diğer senkronizasyon mekanizmalarındaki tanımlarla büyük benzerlikler içerdiğini söylediğimize göre, artık kod örneğimize geçebiliriz:

(*
Ramazan ayı senaryomuz
------------------------------------------------
Anne yarım saat kala yemekleri ısıtmaya başlasın
Baba yarım saat kala sofrayı kurmaya yardım etsin
Çocuk 5 dk kala pide almaya gitsin
Misafir yan gelip yatsın

Ezan okunsun
Herkes orucunu açsın
Anneye teşekkür edilsin(En önemli kısım bu, bunu yapmazsanız anne sizi Terminate eder.)
*)

  TEvAhalisiThread = class(TThread)
  public
    constructor Create;

    procedure TvSeyret;
    procedure SohbetEt;
    procedure OrucunuAc;
  end;

  TAnneThread = class(TEvAhalisiThread)
  private
    fMessage : String;

    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure YemekleriIsit;
    procedure Elhamdulillah;
  end;

  TBabaThread = class(TEvAhalisiThread)
  private
    fMessage : String;

    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure SofrayiKur;
    procedure Elhamdulillah;
  end;

  TCocukThread = class(TEvAhalisiThread)
  private
    fMessage : String;

    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure PideAl;
    procedure Elhamdulillah;
  end;

  TMisafirlerThread = class(TEvAhalisiThread)
  private
    fMessage : String;

    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure Elhamdulillah;
  end;

  TZamanThread = class(TThread)
  private
    fIftarSaati : TTime;

    bAnneYemekleriIsit : Boolean;
    bPideAlmayaGit      : Boolean;
    bEzanOkundu	      : Boolean;

    procedure EzanOkundu;
  protected
    procedure Execute; override;
  public
    constructor Create(const IftarSaati : TTime);
  end;

var
  Form1: TForm1;

  Event_AnneYemekleriIsit,
  Event_CocukPideAlmayaGit,
  Event_BabaSofrayiKur,
  Event_EzanOkundu	: THandle;
...
...

Yukarıdaki kod tanımlarımızda TAnneThread, TBabaThread, TCocukThread, TMisafirlerThread ve TZamanThread isimli sınıfları görüyorsunuz. Bu sınıflar birbirleri ile etkileşimde olan sınıflardır. Ve herbirisi TZamanThread’in vereceği komutlar ile kendilerine has görevlerini yapacaklardır. Şimdi arzu ederseniz kodumuza devam edelim, bakalım nasıl bir iletişim halindeler;

procedure TForm1.FormCreate(Sender: TObject);
var
  Error : DWord;
begin
  Event_AnneYemekleriIsit := OpenEvent(EVENT_ALL_ACCESS, false, PAnsiChar('Event Anne Yemekleri Isit'));
  if Event_AnneYemekleriIsit = 0 then
  begin
    Memo1.Lines.Add('Event bulunamadı, oluşturulacak.');
    Event_AnneYemekleriIsit := CreateEvent(nil, false, false, PAnsiChar('Event Anne Yemekleri Isit'));
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
    	Memo1.Lines.Add('Event Anne Yemekleri Isit ismi daha önce event harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Event bulundu ve OpenEvent ile açıldı.');

  Event_BabaSofrayiKur := OpenEvent(EVENT_ALL_ACCESS, false, PAnsiChar('Event Baba Sofrayı Kur'));
  if Event_BabaSofrayiKur = 0 then
  begin
    Memo1.Lines.Add('Event bulunamadı, oluşturulacak.');
    Event_BabaSofrayiKur := CreateEvent(nil, false, false, PAnsiChar('Event Baba Sofrayı Kur'));
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
    	Memo1.Lines.Add('Event Baba Sofrayı Kur ismi daha önce event harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Event bulundu ve OpenEvent ile açıldı.');

  Event_CocukPideAlmayaGit := OpenEvent(EVENT_ALL_ACCESS, false, PAnsiChar('Event Cocuk Pide Almaya Git'));
  if Event_CocukPideAlmayaGit = 0 then
  begin
    Memo1.Lines.Add('Event bulunamadı, oluşturulacak.');
    Event_CocukPideAlmayaGit := CreateEvent(nil, false, false, PAnsiChar('Event Cocuk Pide Almaya Git'));
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
    	Memo1.Lines.Add('Event Cocuk Pide Almaya Git ismi daha önce event harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Event bulundu ve OpenEvent ile açıldı.');

  Event_EzanOkundu := OpenEvent(EVENT_ALL_ACCESS, false, PAnsiChar('Event Ezan Okundu'));
  if Event_EzanOkundu = 0 then
  begin
    Memo1.Lines.Add('Event bulunamadı, oluşturulacak.');
    Event_EzanOkundu := CreateEvent(nil, true, false, PAnsiChar('Event Ezan Okundu')); // Buraya dikkat, ikinci parametre True.!
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
    	Memo1.Lines.Add('Event Ezan Okundu ismi daha önce event harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Event bulundu ve OpenEvent ile açıldı.');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  CloseHandle(Event_AnneYemekleriIsit);
  CloseHandle(Event_BabaSofrayiKur);
  CloseHandle(Event_CocukPideAlmayaGit);
  CloseHandle(Event_EzanOkundu);
end;

{ TEvAhalisiThread }

constructor TEvAhalisiThread.Create;
begin
  inherited Create(true);
  FreeOnTerminate := true;

  Resume;
end;

procedure TEvAhalisiThread.OrucunuAc;
begin
  // Orucumuzu açalım..
end;

procedure TEvAhalisiThread.SohbetEt;
begin
  // Ahali ile sohbet et..
end;

procedure TEvAhalisiThread.TvSeyret;
begin
  // Arada TV seyret..
end;

{ TAnneThread }
procedure TAnneThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TAnneThread.Elhamdulillah;
begin
  fMessage := 'Anne: Afiyet olsun.';

  Synchronize(Soyle);
end;

procedure TAnneThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Event_AnneYemekleriIsit, INFINITE);
    YemekleriIsit;

    WaitForSingleObject(Event_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(400);
    Elhamdulillah;

    Terminate;
  end;
end;

procedure TAnneThread.YemekleriIsit;
begin
  fMessage := 'Anne: Yemekleri ısıtmaya başladım.:' + TimeToStr(Time);
  Synchronize(Soyle);

  SetEvent(Event_BabaSofrayiKur); // Gerçek hayatta yemekleri ısıtmaya başlamış olan anne, babaya da sofrayı kurması yönünde ricada bulunur.
end;

{ TBabaThread }
procedure TBabaThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TBabaThread.Elhamdulillah;
begin
  fMessage := 'Baba: Hanım eline sağlık.';

  Synchronize(Soyle);
end;

procedure TBabaThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Event_BabaSofrayiKur, INFINITE);
    SofrayiKur;

    WaitForSingleObject(Event_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(100);
    Elhamdulillah;

    Terminate;
  end;
end;

procedure TBabaThread.SofrayiKur;
begin
  fMessage := 'Baba: Bende sofrayı kurmaya başladım:' + TimeToStr(Time);

  Synchronize(Soyle);
end;

{ TCocukThread }
procedure TCocukThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TCocukThread.Elhamdulillah;
begin
  fMessage := 'Çocuk: Anneciğim ellerine sağlık';

  Synchronize(Soyle);
end;

procedure TCocukThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Event_CocukPideAlmayaGit, INFINITE);
    PideAl;

    WaitForSingleObject(Event_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(200);
    Elhamdulillah;

    Terminate;
  end;
end;

procedure TCocukThread.PideAl;
begin
  fMessage := 'Çocuk: Anne ben pide almaya gidiyorum.:' + TimeToStr(Time);

  Synchronize(Soyle);
end;

{ TMisafirlerThread }
procedure TMisafirlerThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TMisafirlerThread.Elhamdulillah;
begin
  fMessage := 'Misafir: Yenge ellerine sağlık nefis olmuş';

  Synchronize(Soyle);
end;

procedure TMisafirlerThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Event_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(300);
    Elhamdulillah;

    Terminate;
  end;
end;

{ TZamanThread }
procedure TZamanThread.EzanOkundu;
begin
  form1.Memo1.Lines.Add('Ezan okundu:' + TimeToStr(Time));
end;

constructor TZamanThread.Create(const IftarSaati: TTime);
begin
  inherited Create(true); // Bekler vaziyette oluştur..
  FreeOnTerminate := true;

  fIftarSaati := IftarSaati;

  bAnneYemekleriIsit := false;
  bPideAlmayaGit      := false;
  bEzanOkundu	    := false;

  Resume;
end;

procedure TZamanThread.Execute;
var
  CurrentTime : TTime;
begin
  inherited;

  while not Terminated do
  begin
    CurrentTime := Time;

    if (IncMinute(CurrentTime, 30) >= fIftarSaati) and (not bAnneYemekleriIsit) then // O anki zamana 30 dk eklenince iftar zamanını geçiyor ise..
    begin
      SetEvent(Event_AnneYemekleriIsit);
      bAnneYemekleriIsit := true;
    end;

    If (IncMinute(CurrentTime, 5) >= fIftarSaati) and (not bPideAlmayaGit) then
    begin
      SetEvent(Event_CocukPideAlmayaGit);
      bPideAlmayaGit := true;
    end;

    if CurrentTime >= fIftarSaati then
    begin
      SetEvent(Event_EzanOkundu);
      bEzanOkundu := true;
      Synchronize(EzanOkundu);
    end;

    if not bEzanOkundu
    then Sleep(1000) // 1 saniyede bir kontrol edelim..
    else Terminate;
  end;
end;

procedure TForm1.btnEventClick(Sender: TObject);
var
  thrdZaman 	: TZamanThread;
  thrdAnne		: TAnneThread;
  thrdBaba		: TBabaThread;
  thrdCocuk		: TCocukThread;
  thrdMisafir        : TMisafirlerThread;
begin
  // edtIftarSaati TEdit türünde bir component'tir ve içine girilen değer; 18:30:00 gibidir..
  thrdZaman 	:= TZamanThread.Create(StrToTime(edtIftarSaati.Text));

  thrdAnne		:= TAnneThread.Create;
  thrdBaba		:= TBabaThread.Create;
  thrdCocuk 	:= TCocukThread.Create;
  thrdMisafir        := TMisafirlerThread.Create;
end;

Yukarıdaki örneğimizde oluşturulan 5 ayrı thread gözlemliyorsunuz. Bu thread’lerden TZamanThread herşeyi kontrol eden thread’imizdir. Diğer thread’ler tanımlı olan event senkronizasyon nesnelerini bekleyerek kendilerine has işlemleri gerçekleştirirler. TZamanThread sınıfımızın Execute metoduna baktığımızda, kendisine geçilen iftar saati bilgisini sürekli kontrol ettiğini görürürüz. İftar saatine yarım saat kalması durumunda, SetEvent API’si yardımı ile “Event_AnneYemekleriIsit” event değişkenimizi tetiklemiş olur(Kapıyı açar).

Bu tetiklemeye kadar TAnneThread, Execute metodu içindeki WaitForSingleObject(Event_AnneYemekleriIsit, INFINITE); satırı vasıtası ile bekler durumdadır. Event nesnesinin set edilmesine müteakip, bu satırın altına geçebilmiştir(Yemekleri ısıtmaya başlamıştır). Yemekleri ısıtmasının bitmesinden sonra WaitForSingleObject(Event_EzanOkundu, INFINITE); kodu ile ezanın okunmasını beklemeye başlamıştır.

TBabaThread ise Execute metodunda, “Event_BabaSofrayiKur” isimli senkronizasyon nesnesini beklemektedir. TAnneThread.YemekleriIsit metodu içindeki SetEvent ile baba thread’de beklemeyi bırakmış ve sofrayı kurma görevine başlamıştır. Ardından o da tıpkı anne thread’de olduğu gibi ezanın okunmasını bekleyecektir.

TZamanThread iftar’a 5 dakika kala, “Event_CocukPideAlmayaGit” isimli senkronizasyon nesnesini tetikleyecektir. Bu sayede TCocukThread beklemekte olduğu emri alır ve pide almak üzere yola koyulur. Pideleri alıp geri geldiğinde o da diğerleri gibi ezanın okunması için beklemeye başlar.

Bu arada TMisafirThread’imizin Execute metodunda kendisine biçilmiş herhangi bir görevi olmadığını, sadece ezanın okunmasını beklediğini görebilirsiniz. Biz Türk milletinin hasletinde olduğu gibi misafirperverliğimiz sanal dünyada thread’ler içinde dahi devam etmelidir

Nihayet ezan vakti geldiğinde TZamanThread’imiz SetEvent(Event_EzanOkundu); API’si yardımı ile event nesnesini tetikleyecek ve bu event’i bekleyen anne, baba, çocuk ve misafir thread’ler bir sonraki kod bloğuna yani OrucunuAc‘a geçebileceklerdir. Ardından zaman thread’imiz Terminate kodunu çağırarak TThread sınıfının Terminated property’sinin true olmasını sağlayacak ve sonsuz döngüden çıkacak, yani threadimiz sonlanacaktır.

Yukarıdaki kod örneğimizde “Event_EzanOkundu” olayının CreateEvent ile oluşturulması koduna bir dikkat ! uyarısı yazmıştım. Hatırlarsanız CreateEvent’in ikinci parametresi bizim event senkronizasyon nesnesinin açık/kapalı olma durumunu otomatik’mi yoksa manuel’mi yapacağımıza karar veren parametre idi. Biz ezan okunması için manuel ayarı seçtik. Bunun sebebi, bu event senkronizasyon nesnesini bekleyen birden fazla thread’in olması ve bizim bu thread’lerin hepsinin birden bekler durumdan kurtulmasını istememizdi.

Eğer parametremizi true değilde false olarak geçse idik, SetEvent ile tetiklenen ezan senkronizasyon nesnesi, tetiklenir tetiklenmez anında tekrar kapalı duruma geçecekti ve dolayısı ile sadece bir thread bekler durumdan kurtulabilecek diğerleri hâla bekler durumda kalacaktı. Halk dili ile, sadece bir kişi orucunu açacak, diğerleri ona bakacak ve kıyamet bundan kopacaktı

Bizde kıyametin kopmasını istemediğimiz için event senkronizasyon nesnesinin açık/kapalı olması durumunu otomatiğe bağlamadık, biz kontrol edeceğiz dedik. Ve açık duruma geldikten sonra, herhangi bir yerde ResetEvent metodunu çağırmadığımız için durum açık olarak kaldı.

Örneğimizi denediğinizde, göreceğiniz çıktı;

gibi olacaktır. Gördüğünüz gibi, Event senkronizasyon mekanizması belirli bir olayı beklemeye dayalıdır. Olayın gerçeklenme koşulunu sizler yönetirsiniz. Kimi zaman bu bir tuşa basma ile gerçekleşir, kimi zaman bir button yada check box’a bastırırsınız yada bizim örneğimizde olduğu gibi bir TZamanThread ile olayları kontrol edersiniz. Bu tamamen sizin ihtiyaçlarınız ile doğru orantılıdır.

Event senkronizasyon mekanizmasını az çok anlattıktan sonra, bir diğer mekanizmamız olan Waitable Timer kavramına göz gezdirebiliriz. Adından da anlaşılabileceği üzere bu bir timer senkronizasyon nesnedir. Ancak, normal timer’lar gibi değildir. Normal timer olaylarında, işletim sisteminin bir pencereye ihtiyacı vardır. Bu pencereye belirli periotlarda WM_TIMER mesajları gönderilir. Oysa bu mekanizma için herhangi bir penceresel denetime ihtiyaç yoktur ve timer nesnelerinden çok daha hassastır. İşletim sistemindeki timer nesneleri mesaj tabanlı oldukları için bir pencereye ihtiyaç duyarlar ve hassasiyetleri yaklaşık olarak 40-50 milisaniyeler civarındadır. Daha kısa zaman aralıklarına sahip işlemler yapmayı arzu ediyor iseniz o zaman WaitableTimer’ları kullanabilirsiniz. Çünkü Waitable Timer’lar 100 nano saniye hassasiyete sahiptir.

Özet ile diğer senkronizasyon mekanizmalarında olduğu gibi çalışırlar. Sizin vereceğiniz zaman dilimi geçildiğinde senkronizasyon nesnesini açar yada kapatırlar. Hatırlayacağınız üzere yukarıdaki örneğimizde biz bu işi TZamanThread ile yapıyorduk. Şimdi yukarıdaki örneğimizi, Waitable Timer senkronizasyon nesnesine göre yeniden yazacağız. Ancak öncelikle herzamanki gibi tanımlarımıza bir göz gezdirelim:

HANDLE CreateWaitableTimer(
    LPSECURITY_ATTRIBUTES lpTimerAttributes,
    BOOL bManualReset,
    LPCTSTR lpTimerName
   );	

HANDLE OpenWaitableTimer(
    DWORD dwDesiredAccess,
    BOOL bInheritHandle,
    LPCTSTR lpTimerName
   );	

BOOL SetWaitableTimer(
    HANDLE hTimer,
    const LARGE_INTEGER *pDueTime,
    LONG lPeriod,
    PTIMERAPCROUTINE pfnCompletionRoutine,
    LPVOID lpArgToCompletionRoutine,
    BOOL fResume
   );

function CreateWaitableTimer(lpTimerAttributes: PSecurityAttributes; bManualReset: BOOL; lpTimerName: PChar): THandle; stdcall;

function OpenWaitableTimer(dwDesiredAccess: DWORD; bInheritHandle: BOOL;
  lpTimerName: PChar): THandle; stdcall;

function SetWaitableTimer(hTimer: THandle; var lpDueTime: TLargeInteger;
  lPeriod: Longint; pfnCompletionRoutine: TFNTimerAPCRoutine;
  lpArgToCompletionRoutine: Pointer; fResume: BOOL): BOOL; stdcall;

Görüldüğü gibi bu senkronizasyon mekanizmasının metodlarının biraz daha farklı parametreleri var. CreateWaitableTimer yada OpenWaitableTimer metodları diğer senkronizasyon mekanizmalarında olduğu gibi benzerlikler arz ediyor. Lâkin, SetWaitableTimer şimdiye dek gördüklerimizden farklı bir yapıya sahip. Waitable Timer’lar tetikleme zamanı için geçeceğiniz zaman bilgisinin TSystemTime, TFileTime türleri arasındaki geçişleri ile ilgili bazı tür dönüşümleri gerektirirler. Gelin kullanımlarına geçmeden evvel ihtiyaç duyacağımız parametre tiplerine yakından bakalım;

  PLargeInteger = ^TLargeInteger;
  _LARGE_INTEGER = record
    case Integer of
    0: (
      LowPart: DWORD;
      HighPart: Longint);
    1: (
      QuadPart: LONGLONG);
  end;
  TLargeInteger = Int64;
  LARGE_INTEGER = _LARGE_INTEGER;

  PSystemTime = ^TSystemTime;
  _SYSTEMTIME = record
    wYear: Word;
    wMonth: Word;
    wDayOfWeek: Word;
    wDay: Word;
    wHour: Word;
    wMinute: Word;
    wSecond: Word;
    wMilliseconds: Word;
  end;
  TSystemTime = _SYSTEMTIME;
  SYSTEMTIME = _SYSTEMTIME;

  PFileTime = ^TFileTime;
  _FILETIME = record
    dwLowDateTime: DWORD;
    dwHighDateTime: DWORD;
  end;
  TFileTime = _FILETIME;
  FILETIME = _FILETIME;

Bir Waitable Timer ‘a zaman bilgisini geçebilmemiz için öncelikle TSystemTime türündeki record değişkenimizin içerisine gerekli bilgileri yazmalı, ardından SystemTimeToFileTime API’si ile gerekli dönüşümü sağlamalı, LocalFileTimeToFileTime ile bir dönüşüm daha sağladıktan sonra TLargeInteger türündeki parametremizin yüksek ve düşük word’lerine gereken atamaları yapmalıyız. Karmaşık gibi görünen bu anlatım aslında göründüğü kadar karmaşık değil. Bunu yazacağımız kodda sizlerde gözlemleyebileceksiniz. Ancak kodlara geçmeden evvel teorik bilgileri vermeye devam etmekte fayda olduğu kanaatindeyim.

SetWaitableTimer’ın üçüncü parametresi Waitable timer’ın ne kadar zamanda bir çalışacağını ifade eder. Biz bu değere 1000 geçerek 1 saniyede bir kontrol etmesini isteyeceğiz. Dördüncü ve beşinci parametreler, waitable timer senkronizasyon mekanizmasının belirtilen zamana eriştiğinde çağırmasını istediğiniz bir metod var ise anlamlı olacaktır. Dördüncü parametrenin Delphi’deki tanım şekli aşağıdaki gibi olacaktır:

procedure (lpArgToCompletionRoutine: Pointer;
    dwTimerLowValue, dwTimerHighValue: DWORD); stdcall;

Beşinci parametre ise herhangi bir geçerli pointer adresi olabilir. Ancak biz örneğimizde bu iki parametreyi de nil olarak geçeceğiz. Çünkü APC(Asynchronous Procedure Call) adı verilen tekniğin detaylarına girmek istemiyorum, bunu sizin araştırmalarınıza bırakıyorum. Yalnız bir ipucu olarak, APC çağrılarının uygulama kuyruğuna eklendiğini ve bu çağrıları yakalayabilmek için SetWaitableTimer API’sini çağıran thread’de SleepEx(INFINITE, true) ile beklemeniz gerektiğini söyleyebilirim. Bu beklemeyi yapmadığınız zaman APC çağrılarını yakalayamazsınız.

Örneğimize geçmeden evvel OpenWaitableTimer için gereken bazı sabitlerin Delphi’de tanımlı olmadıklarını hatırlatmak ve bu tanımları sizlerle paylaşmak isterim;

const
 TIMER_QUERY_STATE  = $0001;
 TIMER_MODIFY_STATE = $0002;

 TIMER_ALL_ACCESS = STANDARD_RIGHTS_REQUIRED or SYNCHRONIZE or TIMER_QUERY_STATE or TIMER_MODIFY_STATE;

Evet, tüm bu sıkıcı teorisel bilgilerin ardından isterseniz iftar ile ilgili örneğimizi, Waitable Timer senkronizasyon mekanizmasını kullanarak ve ana yapımızı pek de değiştirmeden nasıl kodlayabileceğimize yakinen bakalım:

type
  TEvAhalisiThread = class(TThread)
  public
    constructor Create;

    procedure TvSeyret;
    procedure SohbetEt;
    procedure OrucunuAc;
  end;

  TAnneThread = class(TEvAhalisiThread)
  private
    fMessage : String;
    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure YemekleriIsit;
    procedure Elhamdulillah;
  end;

  TBabaThread = class(TEvAhalisiThread)
  private
    fMessage : String;
    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure SofrayiKur;
    procedure Elhamdulillah;
  end;

  TCocukThread = class(TEvAhalisiThread)
  private
    fMessage : String;
    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure PideAl;
    procedure Elhamdulillah;
  end;

  TMisafirlerThread = class(TEvAhalisiThread)
  private
    fMessage : String;
    procedure Soyle;
  protected
    procedure Execute; override;
  public
    procedure Elhamdulillah;
  end;

var
  Form1: TForm1;

  Waitable_AnneYemekleriIsit,
  Waitable_CocukPideAlmayaGit,
  Waitable_EzanOkundu		: THandle;

implementation

procedure TForm1.FormCreate(Sender: TObject);
var
  Error : DWord;
begin
  Waitable_AnneYemekleriIsit := OpenWaitableTimer(TIMER_ALL_ACCESS, false, PAnsiChar('Waitable Anne Yemekleri Isit'));
  if Waitable_AnneYemekleriIsit = 0 then
  begin
    Memo1.Lines.Add('Waitable Timer bulunamadı, oluşturulacak.');
    Waitable_AnneYemekleriIsit := CreateWaitableTimer(nil, false, PAnsiChar('Waitable Anne Yemekleri Isit'));
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
    	Memo1.Lines.Add('Waitable Anne Yemekleri Isit ismi daha önce Waitable Timer harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Waitable Timer bulundu ve OpenWaitableTimer ile açıldı.');

  Waitable_CocukPideAlmayaGit := OpenWaitableTimer(TIMER_ALL_ACCESS, false, PAnsiChar('Waitable Cocuk Pide Almaya Git'));
  if Waitable_CocukPideAlmayaGit = 0 then
  begin
    Memo1.Lines.Add('Waitable Timer bulunamadı, oluşturulacak.');
    Waitable_CocukPideAlmayaGit := CreateWaitableTimer(nil, false, PAnsiChar('Waitable Cocuk Pide Almaya Git'));
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
    	Memo1.Lines.Add('Waitable Cocuk Pide Almaya Git ismi daha önce Waitable Timer harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Waitable Timer bulundu ve OpenWaitableTimer ile açıldı.');

  Waitable_EzanOkundu := OpenWaitableTimer(TIMER_ALL_ACCESS, false, PAnsiChar('Waitable Ezan Okundu'));
  if Waitable_EzanOkundu = 0 then
  begin
    Memo1.Lines.Add('Waitable Timer bulunamadı, oluşturulacak.');
    Waitable_EzanOkundu := CreateWaitableTimer(nil, true, PAnsiChar('Waitable Ezan Okundu')); // İkinci parametreye dikkat, eventlerdeki açıklamamızı hatırlayınız.
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
    	Memo1.Lines.Add('Waitable Ezan Okundu ismi daha önce Waitable Timer harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Waitable Timer bulundu ve OpenWaitableTimer ile açıldı.');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  CloseHandle(Waitable_AnneYemekleriIsit);
  CloseHandle(Waitable_CocukPideAlmayaGit);
  CloseHandle(Waitable_EzanOkundu);
end;

{ TEvAhalisiThread }

constructor TEvAhalisiThread.Create;
begin
  inherited Create(true);
  FreeOnTerminate := true;

  Resume;
end;

procedure TEvAhalisiThread.OrucunuAc;
begin
  // Orucumuzu açalım..
end;

procedure TEvAhalisiThread.SohbetEt;
begin
  // Ahali ile sohbet et..
end;

procedure TEvAhalisiThread.TvSeyret;
begin
  // Arada TV seyret..
end;

{ TAnneThread }

procedure TAnneThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TAnneThread.Elhamdulillah;
begin
  fMessage := 'Anne: Afiyet olsun.';

  Synchronize(Soyle);
end;

procedure TAnneThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Waitable_AnneYemekleriIsit, INFINITE);
    YemekleriIsit;

    WaitForSingleObject(Waitable_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(400);
    Elhamdulillah;

    Terminate;
  end;
end;

procedure TAnneThread.YemekleriIsit;
begin
  fMessage := 'Anne: Yemekleri ısıtmaya başladım.:' + TimeToStr(Time);
  Synchronize(Soyle);
end;

{ TBabaThread }

procedure TBabaThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TBabaThread.Elhamdulillah;
begin
  fMessage := 'Baba: Hanım eline sağlık.';

  Synchronize(Soyle);
end;

procedure TBabaThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Waitable_AnneYemekleriIsit, INFINITE);
    SofrayiKur;

    WaitForSingleObject(Waitable_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(100);
    Elhamdulillah;

    Terminate;
  end;
end;

procedure TBabaThread.SofrayiKur;
begin
  fMessage := 'Baba: Bende sofrayı kurmaya başladım:' + TimeToStr(Time);

  Synchronize(Soyle);
end;

{ TCocukThread }

procedure TCocukThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TCocukThread.Elhamdulillah;
begin
  fMessage := 'Çocuk: Anneciğim ellerine sağlık';

  Synchronize(Soyle);
end;

procedure TCocukThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Waitable_CocukPideAlmayaGit, INFINITE);
    PideAl;

    WaitForSingleObject(Waitable_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(200);
    Elhamdulillah;

    Terminate;
  end;
end;

procedure TCocukThread.PideAl;
begin
  fMessage := 'Çocuk: Anne ben pide almaya gidiyorum.:' + TimeToStr(Time);

  Synchronize(Soyle);
end;

{ TMisafirlerThread }

procedure TMisafirlerThread.Soyle;
begin
  form1.Memo1.Lines.Add(fMessage);
end;

procedure TMisafirlerThread.Elhamdulillah;
begin
  fMessage := 'Misafir: Yenge ellerine sağlık nefis olmuş';

  Synchronize(Soyle);
end;

procedure TMisafirlerThread.Execute;
begin
  inherited;

  while not Terminated do
  begin
    TvSeyret;
    SohbetEt;

    WaitForSingleObject(Waitable_EzanOkundu, INFINITE);
    OrucunuAc;

    Sleep(300);
    Elhamdulillah;

    Terminate;
  end;
end;

procedure TForm1.btnWaitableTimerClick(Sender: TObject);
type
  TInt64Rec = record
    Lo : DWord;
    Hi : DWord;
  end;
var
  SysTime : TSystemTime;

  ft,
  ftResult: TFileTime;
  li : Int64;

  IftarZamani : TTime;
  wGun,
  wAy,
  wYil,
  wSaat,
  wDakika,
  wSaniye,
  wMiliSaniye : Word;

  thrdAnne		: TAnneThread;
  thrdBaba		: TBabaThread;
  thrdCocuk		: TCocukThread;
  thrdMisafir        : TMisafirlerThread;
begin
  IftarZamani := StrToTime(edtIftarSaati.Text);

  DecodeDate(Date, wYil, wAy, wGun);
  DecodeTime(IftarZamani, wSaat, wDakika, wSaniye, wMiliSaniye);

  SysTime.wYear 		:= wYil;
  SysTime.wMonth 	:= wAy;
  SysTime.wDayOfWeek := 0;
  SysTime.wDay 		:= wGun;
  SysTime.wHour 		:= wSaat;
  SysTime.wMinute 	:= wDakika;
  SysTime.wSecond     	:= wSaniye;
  SysTime.wMilliseconds := 0;

  SystemTimeToFileTime(SysTime, ft);
  LocalFileTimeToFileTime(ft, ftResult);

  TInt64Rec(li).Lo := ftResult.dwLowDateTime;
  TInt64Rec(li).Hi := ftResult.dwHighDateTime;

  SetWaitableTimer(Waitable_EzanOkundu, li, 1000, nil, nil, false);

  DecodeTime(IncMinute(IftarZamani, -30), wSaat, wDakika, wSaniye, wMiliSaniye); // Annenin yemekleri ısıtacağı zaman..
  SysTime.wHour     := wSaat;
  SysTime.wMinute  := wDakika;
  SysTime.wSecond := wSaniye;

  SystemTimeToFileTime(SysTime, ft);
  LocalFileTimeToFileTime(ft, ftResult);

  TInt64Rec(li).Lo := ftResult.dwLowDateTime;
  TInt64Rec(li).Hi := ftResult.dwHighDateTime;
  SetWaitableTimer(Waitable_AnneYemekleriIsit, li, 1000, nil, nil, false);

  DecodeTime(IncMinute(IftarZamani, -5), wSaat, wDakika, wSaniye, wMiliSaniye); // Çocuğun pide almaya gideceği zaman..
  SysTime.wHour     := wSaat;
  SysTime.wMinute  := wDakika;
  SysTime.wSecond := wSaniye;

  SystemTimeToFileTime(SysTime, ft);
  LocalFileTimeToFileTime(ft, ftResult);

  TInt64Rec(li).Lo := ftResult.dwLowDateTime;
  TInt64Rec(li).Hi := ftResult.dwHighDateTime;
  SetWaitableTimer(Waitable_CocukPideAlmayaGit, li, 1000, nil, nil, false);

  thrdAnne		:= TAnneThread.Create;
  thrdBaba		:= TBabaThread.Create;
  thrdCocuk 	:= TCocukThread.Create;
  thrdMisafir        := TMisafirlerThread.Create;
end;

Evet hepsi bu kadar. Gördüğünüz gibi diğerlerine nazaran tek zorluğu SetWaitableTimer API’sinin parametrelerinde yaşadık. Geri kalan kullanım diğer senkronizasyon nesnelerinde izah ettiğimiz gibi gerçekleşiyor. Bu örneğimizde zamanlamayı kontrol etmek maksadı ile daha evvel kullandığımız TZamanThread sınıfına ihtiyacımız olmadı. Çünkü zamanlama bilgisini Waitable Timer’lar ile sağlıyoruz. Belirttiğimiz zaman geldiğinde, Waitable Timer senkronizasyon nesnesi otomatikman açık duruma geçecek, dolayısı ile bu senkronizasyon nesnelerini WaitForSingleObject yada WaitForMultipleObjects ile bekleyen thread’lerimiz çalışmalarına kaldıkları yerden devam edebilme şansını elde edebileceklerdir.

Bu konularla ilgili herhangi bir görüş, düşünce yada öneriniz var ise yorum olarak paylaşmanızdan bilhassa memnuniyet duyarım. Bundan sonra yazacağım küçük makale bir thread’in TerminateThread kullanılmadan düzgün bir şekilde nasıl kapatılacağına yönelik olacaktır.

Bir sonraki makalede görüşmek ümidi ile hoşçakalın..

Thread’lerle düzgün şekilde çalışabilmek için öncelikle çok derin olmasa da orta seviyede işletim sistemi çalışma mekanizmasına aşina olmalıyız. Bu bağlamda işletim sistemleri üzerinde nispeten az bilinen hususlara değinmeye çalışacağım.

İyi bir programcı, üzerinde çalıştığı işletim sistemini tanıyan, onun neleri yapabileceğini ve neleri yapamayacağını bilen programcıdır. Bu öngörü, her zaman düşük seviyeli işletim sistemi bilgilerine müracaat etmeniz gerektiği anlamına gelmez. Yüksek seviye bir dil de kullanabiliyor olabilirsiniz, ancak her zaman olayın arka planında neler olduğunu bilen bir programcı diğerlerine oranla basamaklarca önde olacaktır. Tercih tamamen sizlere aittir. “Çok derin bilgilere girmem, bildiklerim bana yeter, ekmeğimi kazanırım keyfime bakarım” düşüncesinde iseniz, bildiklerinizin size yetmeyeceği gerçeği ile birgün karşılaşacağınızı üzülerek ifade etmek zorunda kalacağım. Her geçen gün sürekli değişen bir bilişim dünyasında kalıcı olabilmeniz; temel seviye bilgilerinizin yüksekliği ile doğrudan orantılıdır.

Yüzyüze karşılaştığım, yada bir şekilde derinlemesine programlama alemi ile ilgili muhabbete girdiğim arkadaşlarıma verdiğim tavsiyeler hep bu yönde olmuştur. Benim kişisel kanım, iyi bir programcının her zaman üzerinde çalıştığı sistem hakkında bilgiye haiz olması üzerinedir. Hemen hemen her programcı, günümüz popüler dillerinde nesneye yönelik programlamayı, pointer’ları ve daha pek çok low level teknolojiyi farkında olarak yada olmayarak kullanmaktadır. Dileğim odur ki, sizler farkında olanların safında olun. Bu farkındalık, sadece şahsınıza değil; şahsınız nezdinde pek çok insana ve hatta ülkenize de faydanız olacağı mânasına gelir.

Blog’umuz genel mânada Delphi üzerine olduğu için vereceğim örnekler Delphi üzerine olacaktır ama bu söylemler programlama ile uğraşan herkesi ilgilendirir. Delphi’ye yeni başlayan birisi dahi olsanız, farkında olmadan pointer’ları kullanıyor, nesneye yönelik programlama dünyasının avantajlarından sonuna kadar istifade ediyor, design pattern denilen popüler programlama konseptlerini programlarınızda kullanıyorsunuz demektir. Delphi, bu derin bilgi gerektiren hususların kullanım zorluklarını, kullanıcılarından gizleme konusunda son derece maharetlidir. Makalemde ilerlemeden evvel, her programcı arkadaşıma Delphi’nin kaynak kodlarında dolaşmasını öneriyorum.

Evet, low level bilgi sahibi olmanın önemini dilimiz döndüğünce izah etttikten sonra, kaldığımız yerden devam edebiliriz. Threading, korkulan ama bir zaman geldiğinde kaçılamayan bir konudur. Her programcı hayatının bir döneminde bu konu ile yüzleşecektir. Yüzleştiği zaman diliminde alnınızın akı ile sorunları bertaraf edebilmeniz için sizlere yardımcı olmaya çalışacağım.

Windows işletim sistemleri; multi-threaded işletim sistemleri değillerdir. Sadece bu hususta taklit yaparlar. İşletim sistemi üzerinde çalışan uygulamalara process adı verdildiğini biliyorsunuz. Her bir process, en az bir thread’e sahiptir. Sistem üzerinde çalışan process’ler Task Manager(Görev Yöneticisi) vasıtası ile gözlemlenebilir. Bu konu ile ilgili yazdığım diğer makaleleri de inceleyebilirsiniz.

İşletim sistemimiz içinde çalışan bir çok process ve en az process sayısı kadar thread olduğuna göre, işletim sistemi bu thread’lerin çalışma mekanizmasını nasıl sağlamaktadır ? İşte threading de en az bilinen ama en önemli hususda bu noktadadır. İşletim sistemi çalışan thread’leri belirli bir algoritmaya göre sıra ile çalıştırmaktadır. Yani belli bir t zaman diliminde, işletim sistemi üzerinde yalnızca bir tek thread çalışıyor olacaktır.

Bu durumda diğer thread’ler beklemeye alınmış durumdadırlar. Thread işletim sisteminin belirlediği bir zaman dilimi kadar çalıştırıldıktan sonra, sıradaki diğer thread’e geçilecektir. Bu çizelgeleme işlemine round robin scheduling adı verilir.Peki işletim sisteminin bu mekanizması nasıldır ? Biraz da bu hususa yakından bakmakta fayda var.

İşletim sistemi thread çalıştırmada zaman paylaşımlı bir yapıya sahiptir. Thread’leri belirli zaman dilimlerinde çalıştırır ve bir thread’e ayrılan zaman dolduğunda çalışma sırasındaki diğer thread’e geçilir. İşte bu thread’ler arasındaki geçiş zamanına quanta süresi adı verilir. Ve eğer değişmedi ise Windows işletim sistemlerinde quanta süresi 20 ms. dir. Yani bir thread işletim sisteminde en fazla 20 milisaniye çalışabilir. Bu 20 milisaniyenin dolmasından sonra, sıradaki diğer bir thread çalışacaktır. İşletim sistemi thread’ler arasında son derece hızla geçerek multi-threaded gibi görünmektedir. Bir thread’in maksimum çalışabileceği süre anlık olarak 20 ms’dir ibaresini tekrarlamak istiyorum. Bunu hiçbir zaman unutmayın, çünkü ilerleyen aşamalarda thread programlamada karşılaştığınız tüm problemlerin ve bu problemlerin çözümüne yönelik teknolojilerin ana sebebinin bu olduğunu anlayacaksınız.

Burada aklımıza bir soru geliyor. İşletim sistemi üzerinde o anda çalışan uygulama sayısının 100 olduğunu varsayalım. Bu durumda en azından 100 çalışan thread’imiz var demektir. İşletim sistemi thread’ler arasında 20 ms’lik zaman dilimlerinde geçiş yapıyorsa eğer, en son thread’e 2000 ms. sonra yani 2 sn. sonra mı uğrayacaktır ?
Böyle bir durumda uygulamamız 20 ms. çalışıp 2 sn. beklemek zorunda mı kalacaktır ?

Elbette ki hayır. Hernekadar işletim sistemi dediğimiz gibi thread’ler arasında 20 ms. gibi bir zaman diliminde geçiş yapıyorsa da; bu tarz uzun bekleme problemlerinin engellenmesi adına bir çözüme de sahiptir. Bu çözüme priority(öncelik) adı verilmiştir. İşletim sisteminin thread’leri belli zaman dilimlerinde çalıştırması round robin algoritmasına göredir demiştik; işin içine öncelikler girince bu algoritma priority round robin adını alır.

Bu yöntemde her bir thread belirli bir öncelik seviyesine sahiptir. Öncelik seviyesi yüksek olan thread’ler işletim sistemince daha ön sıralara alınırlar. Aynı öncelik seviyesine sahip olan thread’ler öncelik seviyesi yüksek olandan düşük olana doğru sırası ile işletilirler ve öncelik seviyesi yüksek olan grup tamamlandıktan sonra işletim sistemi diğer grubu çalıştırma cihetine gider. Thread öncelikleri 0-31 aralığında bir sayısal değer ile ifade edilirler.(Bknz.)

Bu durumda, thread’lerin belirli bir öncelik seviyesine göre gruplandığını ve öncelik seviyesi yüksek olanların düşük olanlardan daha önce çalıştırıldığını ve yüksek öncelikli thread’lerin çalışmasının bitmesine müteakip diğer öncelik gurubuna geçildiğini öğrenmiş bulunuyoruz. Örneğin; işletim sisteminde o anda çalışmakta olan thread’lerimizin öncelik seviyeleri aşağıda görüldüğü gibi olsun:

Yukarıdaki gibi bir tabloda işletim sistemi öncelikle Thread-1 ve Thread-4 arasında 20 ms.’lik periyotlar ile geçişler yapacak ve her iki thread’in de bitmesine müteakip öncelik seviyesi 19 olan Thread-2 ve Thread-5′e geçecektir. Sırası ile öncelik seviyesi yüksek olan thread’ler işletilecek ve düşük seviyeli gruba geçiş yapılacaktır.

Yukarıdaki tabloya göre çalıştırılma sırası aşağıdaki gibi olacaktır:

Görüldüğü gibi Thread-6 diğer thread’lere göre çalışmak için çok az zaman bulabilecektir. Ancak işletim sistemi, öncelik seviyesi düşük olan thread’lerin tamamen ölü görünmemesi adına da bazı mekanizmalara sahiptir. Öncelik sistemi düşük olan thread’lerin çalışabilmesi için iki koşul vardır.

Birincisi kendilerinden yüksek önceliğe sahip olan tüm thread’lerin bitmiş olması yada bir nedenden bloke olmuş olmalarıdır. Öncelik seviyesi yüksek olan bir thread SuspendThread ile duraksatılmış olabilir, yada thread içinde bir deadlock oluşmasından ötürü kararsız duruma gelmiş olabilir. Bu durumda öncelik seviyesi daha düşük olan thread’ler çalışma fırsatını yakalayabilirler.

İkinci koşulumuz ise; işletim sisteminin düşük öncelikli thread’lere verdiği bir çalışma şansı ile ilgilidir. Bu şansa dynamic boosting adı verilir. Eğer bir thread, belirli bir zaman boyunca hiç çalışma şansını elde edememiş ise o zaman işletim sistemi bu thread üzerinde dynamic boosting işlemi uygular ve thread’in önceliğini 15 seviyesine yükseltir. Ancak bu yükseltme bir kaç quanta(1 quanta=20 ms.) süresi kadardır. Kendisine işletim sistemi tarafından kıyak geçilen thread, daha sonra tekrar orjinal öncelik seviyesine geri çekilir.

Gördüğünüz gibi, threading’in arka planında son derece hassas mekanizmalar bulunmaktadır. İşletim sistemi gerçek multi-threaded’ı sağlamak adına thread’ler arasında öncelik kavramını yoğun bir şekilde kullanarak aslında bizleri kandırmaktadır İşletim sistemi thread’ler arasında o kadar hızlı geçer ki, biz thread’lerimizin kesintiye uğradığının farkına dahi varmayız.

Peki, biz bu öncelik seviyelerini nasıl kullanacağız ? Öncelik seviyelerinin ne olduğunu az çok anlattık. Ama makalenin amacı gereği daha derinlere inmemiz gerekiyor

Yazdığımız uygulamalarda öncelik seviyelerini istediğimiz gibi ayarlayabiliriz. Öncelik belirleme işlemimiz, process önceliği ve thread önceliği olarak iki kısımda incelenir. İşletim sistemi için bir thread’in önceliği; o thread’e sahip olan process’in önceliği ile thread’in önceliğinin toplamıdır. Öncelik değerlerini MSDN‘den gözlemleyebilirsiniz.

Bir thread’in öncelik değerleri Delphi’de aşağıdaki şekilde tanımlanmıştır:

  THREAD_BASE_PRIORITY_LOWRT = 15;
  THREAD_BASE_PRIORITY_MAX = 2;
  THREAD_BASE_PRIORITY_MIN = -2;
  THREAD_BASE_PRIORITY_IDLE = -15;

  THREAD_PRIORITY_LOWEST              = THREAD_BASE_PRIORITY_MIN;
  THREAD_PRIORITY_BELOW_NORMAL   = THREAD_PRIORITY_LOWEST + 1;
  THREAD_PRIORITY_NORMAL              = 0;
  THREAD_PRIORITY_HIGHEST             = THREAD_BASE_PRIORITY_MAX;
  THREAD_PRIORITY_ABOVE_NORMAL   = THREAD_PRIORITY_HIGHEST - 1;
  THREAD_PRIORITY_ERROR_RETURN    = MAXLONG;

  THREAD_PRIORITY_TIME_CRITICAL    = THREAD_BASE_PRIORITY_LOWRT;
  THREAD_PRIORITY_IDLE                  = THREAD_BASE_PRIORITY_IDLE;

Bu listede özel durumlu iki üye vardır.THREAD_PRIORITY_IDLE ve THREAD_PRIORITY_TIME_CRITICAL.

Thread’ler için bu öncelik seviyelerinin kullanılması; process ve thread öncelik seviye değerlerinin toplanması yerine sabit değere eşitleme yoluna gidilmesine neden olur. THREAD_PRIORITY_IDLE öncelik seviyesinde, işletim sistemi öncelik değerini; thread’in ait olduğu process’in öncelik seviyesinin REALTIME_PRIORITY_CLASS olması durumunda 16 diğer durumlarda 1 olarak ayarlayacaktır.

THREAD_PRIORITY_TIME_CRITICAL öncelik seviyesinde ise işletim sistemi öncelik değerini; thread’in ait olduğu process’in öncelik seviyesinin REALTIME_PRIORITY_CLASS olması durumunda 31 diğer durumlarda 15 olarak ayarlayacaktır.

Bu karmaşık cümleyi, aşağıda pseudo kod ile göstermeye çalışmak sanırım daha kolay anlaşılmasına vesile olacaktır;

function GetOSPriority(const Thread : TThread) : Longint;
begin
  if Thread.Priority = THREAD_PRIORITY_IDLE then
    if Thread.Process.Priority = REALTIME_PRIORITY_CLASS
    then Result := 16
    else Result := 1;

  if Thread.Priority = THREAD_PRIORITY_TIME_CRITICAL then
    if Thread.Process.Priority = REALTIME_PRIORITY_CLASS
    then Result := 31
    else Result := 15;
end;

Buradan gözlemleyebildiğimiz kadarı ile işletim sisteminin thread’leri çalıştırması iki ayrı öncelik seviyesine dayanmaktadır. Process öncelik seviyesi ve thread öncelik seviyesi. Process’ler için öncelik seviyeleri aşağıdaki gibidir;

Yazdığımız uygulamalarda herhangi bir öncelik seviyesi belirtmediğimizde process öncelik seviyesi NORMAL_PRIORITY_CLASS‘a ayarlanır. Thread’lerde ise THREAD_PRIORITY_NORMAL değerine ayarlanmaktadır. Çalışma anında bu değerleri istediğimiz gibi değiştirebiliriz. Bir process’in öncelik seviyesini SetPriorityClass API’si yardımı ile değiştirebileceğimiz gibi, eğer process’i biz oluşturuyor isek CreateProcess API’sine parametre olarak da geçebiliriz. Mevcut bir thread’in öncelik seviyesini ise SetThreadPriority API’sini kullanarak değiştirebileceğimiz gibi, eğer TThread Delphi sınıfını kullanıyorsak bu sınıfın Priority özelliğini değiştirerek de yapabiliriz.

Thread önceliklerinin hayati öneme sahip olduğunu sanıyorum artık anladık. Gerçekten kritik işlemleriniz var ise, process ve thread öncelik seviyelerinizi yüksek değerlerle kullanarak bu işlemlerin diğer thread’lerden daha önce tamamlanmasını sağlayabilirsiniz. Ancak, kantarın topuzunu fazla da kaçırmamak gerekir bu konularda. Her yazdığınız thread’i real time thread olarak yazarsanız, işletim sistemini kararsız duruma sokabilir, yada beklenmeyen yavaşlıklara neden olabilirsiniz.

Şu aşamaya geldiğimizde thread’lerin işletim sistemince nasıl yönetildiğini ve çalışma mekanizmaları hakkında bir nebze de olsa bilgi sahibi olmuş bulunuyoruz. Hâla aklımızda olan ve asla unutmayacağımız 20 ms. lik süreler içinde thread’ler arasında gezilmesi bize halihazırda ne gibi sorunlar getirir konusuna henüz değinmedik. Biraz da bu konuya değinelim arzu ederseniz.

Daha önce de sıklıkla ifade ettiğimiz gibi; işletim sistemi thread’ler arasında her 20 ms. de bir geçişler yapıyordu. Şimdi bir senaryo uyduralım. Bu senaryoda, bir thread programımız içinde tanımlı olan global bir değişkene erişecek ve bu değişkenin değerini kontrol edecek yada değiştirecek.

Bu senaryoda ne gibi bir sorun olabilir sizce ?

Bir sorun olmaz gibi görünüyor, ama eminim sizlerde gerek okuduğunuz bazı kaynaklarda; gerekse de kulaktan dolma bilgilerle thread’ler içinden dış dünyaya erişimlerde dikkatli olmak gerektiğini biliyorsunuzdur. Peki neden dikkatli olmamız gerekiyor , neden bir thread içinden dış dünyaya erişmemiz sorunlara sebep oluyor ? İşte bu soruya yanıt pek bilinmiyor. Maksadımız bu sorunun yanıtını açıklamak ve dolayısı ile thread senkronizasyon mekanizmalarının neden var olduklarını izah etmeye gayret etmek.

Muhtemeldirki thread senkronizasyonlarına yabancı değilsinizdir ve thread’leriniz içinde kullanmışsınızdır. Ancak bu makaleyi okuduktan sonra bu senkronizasyon mekanizmalarına daha bir farklı gözle bakacağınızdan eminim. En yaygın kullanılanlar, critical sectionlar, muteksler, semaphore’lar ve eventlerdir. Yine paragrafımızın başında değindiğimiz soruya bir kere daha gönderme yapalım. Bu mekanizmalar niye var, ne gibi sorunlara önlem alıyor bu birbirinden gizemli mekanizmalar ?

Şimdi örneğimize geri dönelim. Bir thread’imiz olduğunu ve bu thread’in programımız içinde tanımlı olan bir değişkene ulaşacağını söylemiştik. Bunu kısaca kod ile simüle edelim:

var
  iValue : Integer = 10;
..
..
..
procedure TMyThread.Execute;
begin
...
...
  if iValue = 10 then iValue := 50;
end;

Bu son derece masumane kod, bir değişkenin değerinin 10 olup olmadığını kontrol ediyor ve değer 10 ise 50 ataması yapıyor. Aslında burada son derece ciddi problemler olabilir. Burada bakış açımızı biraz daha derinlere çevirmemiz , makina dili seviyesinde düşünmemiz gerekiyor. Yazdığımız tüm kodların makina diline çevrildiğini biliyorsunuz. Masum bir değişkene değer atamanın yada o değişkendeki değeri kontrol etme kodunun dahi makina dilinde bir karşılığı vardır. Bu karşılıkları Delphi’de CPU Window‘u açarak görebilirsiniz.

Bir değişkenin değerinin kontrol edilmesi yada o değişkene değer atanması işlemi makina dilinde birden fazla satıra karşılık geliyor olabilir. Diyelim ki bir değişkenin değerinin kontrol edilmesi, makina dilinde(assembler) 4 satırdan oluşsun ve bu değişkene değer atanması da 6 satırdan oluşsun. Böyle bir durumda işletim sistemi tarafından çalıştırılan thread tam değişkenin değerini kontrol ederken, yani “if Value = 10″ işlemini yaparken makina dili kodlarının 3ncü satırında beklemeye alınırsa(20 ms’lik işletme zamanı dolarsa) ne olur ?

Söylemimizi daha anlaşılır kılmak adına aşağıdaki pseudo koda bakabilirsiniz:

//if iValue = 10
asm
  mov ..
  pop ..
  push.. // Thread 20 ms.'lik çalışma süresini bu noktada bitirir ise !!
  je  ..
end;

// iValue := 50;
asm
  mov ..
  mov ..
  add ..
  pop ..
  push..
  nop ..
end;

Yukarıdaki kodlar tamamen uydurma kodlardır. Amacımız ne demek istediğimizi bu uydurma kodlar ile daha anlaşılır hâle getirmeye çalışmaktır.

Bu durumda geriye kalan 1 satırlık kod henüz işletilmemiş durumdadır. Ve aynı sınıfın bir başka thread’i bu değişkene erişip değişkenin değerini kendi 20 ms. lik zaman diliminde değiştirirse birinci thread hatalı çalışabilir. Bu ve benzeri senaryolar, birden fazla thread’in ortak kaynakları kullandığı her ortamda gerçekleşebilir. İşte bu sebeplerden ötürü, thread’lerde senkronizasyonlar son derece önemlidir. Kritik kod bloklarının birden fazla thread’in erişimi sırasında güvenli duruma getirilmesi gerekir. Buna genellikle atomik erişim adı verilir. İşletim sistemi thread’ler arasındaki zaman paylaşım mekanizmasını kendisi yürütür ve bu mekanizmaya direkt erişime müsaade etmemiştir. Eğer biz işletim sistemine “thread’ler arasında geçiş yapma” diyebilse idik, thread senkronizasyonlarına hiç gerek kalmazdı. Ancak bu derece ciddi bir husus programcıların insiyatifine bırakılmayacak kadar önemli olduğu için bu mekanizma işletim sistemi tarafından yönetilir.

Bir veri kaynağına multi-threaded ortamlarda güvenli(atomik) erişmek için işletim sistemi bize pek çok senkronizasyon fonksiyonu sağlamıştır. Bunlardan InterlockedIncrement, InterlockedCompareExchange, InterlockedDecrement, InterlockedExchange ve InterlockedExchangeAdd metodları thread’lerin global değişkenlere erişimlerini güvenli hale getiren metodlardır. Bu metodların tanım şekilleri aşağıdaki gibidir:

LONG InterlockedIncrement(
  LPLONG lpAddend
);

PVOID InterlockedCompareExchange(
  PVOID *Destination,
  PVOID Exchange,
  PVOID Comperand
);

LONG InterlockedDecrement(
  LPLONG lpAddend
);

LONG InterlockedExchange(
  LPLONG Target,
  LONG Value
);

LONG InterlockedExchangeAdd (
  PLONG Addend,
  LONG Increment
);

ve Delphi tanımları:

  function InterlockedIncrement(var Addend: Integer): Integer; stdcall;
  function InterlockedDecrement(var Addend: Integer): Integer; stdcall;
  function InterlockedExchange(var Target: Integer; Value: Integer): Integer; stdcall;
  function InterlockedCompareExchange(var Destination: Pointer; Exchange: Pointer; Comperand: Pointer): Pointer stdcall;
  function InterlockedExchangeAdd(var Addend: Longint; Value: Longint): Longint stdcall; overload;

Bu bilgiler ışığında yukarıdaki örneğimizi yeniden yazarsak;

var
  iValue : Integer = 10;
..
..
..
procedure TMyThread.Execute;
begin
...
...
  if InterlockedCompareExchange(Pointer(iValue), Pointer(iValue), Pointer(0)) = Pointer(10)
  then InterlockedExchange(iValue, 50);
end;

Gördüldüğü üzere birden fazla thread’in erişebileceği bir değişkenin değerinin kontrolü sırasında InterlockedCompareExchange metodunu, ve bu değişkene değer atarken de InterlockedExchange metodunu kullandık. Bu metodlar ilgili değişkene güvenli bir şekilde erişmemizi ve veriyi düzgün bir şekilde değiştirmemizi sağlarlar. Bu metodların kullanılması thread’in 20 ms. lik çalışma süresinin işletim sistemi tarafında sonuna da gelinmiş olsa, işlem bitmeden bir başka thread’e geçilmeyeceğinin garantisini verir. En önemli özelliklerinin özetlenmesi gerekir ise; işletim sistemi bu metodlar kullanımda iken thread’ler arası geçişi durdurur. Kısacası, bir global değişkenin değerinin değiştirilmesi yada kontrol edilmesi sırasında oluşabilme ihtimali olan thread geçişlerinin önüne set olur ve işleminiz hatasız bir şekilde sonlanır.

InterlockedCompareExchange ilk değer olarak içeriği kontrol edilecek yada değişime uğrayacak değişkenimizin adresini alır. İkinci parametresi ise; kontrol edilecek değerin eşit olması durumunda değiştirilecek bilgiyi içerir. Üçüncü parametre, global değişkenimizin kontrol edileceği değerin adresidir. Global değişkenimiz üçüncü parametredeki değer ile eşit olduğu durumda, 2nci parametrede belirtilen değere set edilir. Fonksiyonun geri dönüş değeri ise InterlockedCompareExchange’den önce global değişkenin
sahip olduğu değerdir. Bu metodun en can alıcı noktası kendisine 32 bit veri türlerini kabul ediyor olmasıdır. İşletim sistemi bu fonksiyona parametre olarak geçilen değerleri kendi içinde 32 bit bir kıyaslamaya tabii tutacaktır.

Bu durumda InterlockedCompareExchange fonksiyonuna sadece 32 bit veri türlerinin geçilmesi gerekir. Bilindiği gibi, işletim sistemi 32 bit olduğu için Pointer türü de 32 bit’dir. Böyle bir durum söz konusu iken 32 bit’ten daha büyük değerlerin bu fonksiyon ile kontrol edilmesi mümkün değildir.Eğer 64 bit global değişkenleriniz var ise ve bu değişkenleri atomik düzeyde kontrol etmek istiyor iseniz, uygulamanızın çalıştığı işletim sisteminin minimum Windows Vista olması gerekir. Windows Vista altında InterlockedCompareExchange64 isimli fonksiyonu 64 bit veri kıyaslaması için kullanabilirsiniz.

Tüm bu açıklamalar bizde Delphi’deki 32 bit harici veri türlerinin atomik olarak nasıl kontrol edileceği hususunda bazı soru işaretleri oluşmasına neden olur. Bu veri türlerinden Boolean en çok kullanılan veri türü sayılabilir. Bir boolean veri türünü global olarak tanımlarsak ve bunu atomik düzeyde InterlockedCompareExchange ile kontrol etmek ister isek ne yapacağız ?

Bildiğiniz gibi Boolean veri türü, 1 Byte’lık(8 bit) yer kaplamaktadır. Oysa fonksiyonumuz 32 bit veri türleri ile çalışır. Bu durumda; Delphi’nin Boolean tipi yerine Win32′deki LongBool veri tipini kullanabilirsiniz. Örneğin;

uses
  StrUtils; // IfThen fonksiyonu için..
..
..
var
  GlobalBool : LongBool = false;
..
..
var
  pResult : Pointer;
begin
  pResult := InterlockedCompareExchange(Pointer(GlobalBool), Pointer(LongBool(true)), Pointer(LongBool(false)));

  if pResult = Pointer(LongBool(true))
  then ShowMessage('Global Boolean değişkenimiz InterlockedCompareExchange den önce True idi')
  else  ShowMessage('Global Boolean değişkenimiz InterlockedCompareExchange den önce false idi');

  ShowMessage('GlobalBool un yeni değeri:' + IfThen(GlobalBoolean, 'Yeni değer True', 'Yeni değer False'));
end;

Yukarıdaki kod örneği; global bir sahada tanımlanmış LongBool türündeki değişkenimizin değerini atomik seviyede kontrol eder ve gerekir ise değiştirir. InterlockedCompareExchange metodunun birinci parametresi global boolean değişkenimizi gösterir. İkinci parametremiz bu değişkenin almasını istediğimiz yeni değeri ifade eder. Üçüncü parametremiz ise global değişkenimizin karşılaştırılacağı değerdir. Fonksiyondan geriye dönen değer, InterlockedCompareExchange fonksiyonunun çağırılmasından evvel global değişkenin sahip olduğu değerdir.

Bu mekanizma işletim sistemindeki thread senkronizasyonlarından sadece bir tanesidir. Eğer uygulamanız içinde kullandığınız thread’lerin global değişkenlere erişimi söz konusu ise, bu metodları kullanmak sizlere güvenli bir kodlamanın yollarını açacaktır.

Critical Section

Bir diğer popüler senkronizasyon mekanizması da; critical section’lardır. Critical Section’lar en bilinen thread senkronizasyon mekanizmalarından bir tanesidirler. Burada amaç; bir thread’in belirli bir kritik kodu çalıştırırken , başka bir thread’in aynı kod bloğuna girmesine mani olmaktır. Bu mekanizmanın en sık kullanılan metodları; InitializeCriticalSection, EnterCriticalSection, LeaveCriticalSection ve DeleteCriticalSection‘dır.

C++ ve Delphi tanımları aşağıdaki gibidir:

VOID InitializeCriticalSection(
  LPCRITICAL_SECTION lpCriticalSection
);

VOID EnterCriticalSection(
  LPCRITICAL_SECTION lpCriticalSection
);

VOID LeaveCriticalSection(
  LPCRITICAL_SECTION lpCriticalSection
);

VOID DeleteCriticalSection(
  LPCRITICAL_SECTION lpCriticalSection
);

_RTL_CRITICAL_SECTION = record
  DebugInfo: PRTLCriticalSectionDebug;
  LockCount: Longint;
  RecursionCount: Longint;
  OwningThread: THandle;
  LockSemaphore: THandle;
  Reserved: DWORD;
end;

  TRTLCriticalSection = _RTL_CRITICAL_SECTION;

  procedure InitializeCriticalSection(var lpCriticalSection: TRTLCriticalSection); stdcall;
  procedure EnterCriticalSection(var lpCriticalSection: TRTLCriticalSection); stdcall;
  procedure LeaveCriticalSection(var lpCriticalSection: TRTLCriticalSection); stdcall;
  procedure DeleteCriticalSection(var lpCriticalSection: TRTLCriticalSection); stdcall;

Critical Section’lar thread programlamada sıklıkla kullanılan ama aynı zamanda sıklıkla yanlış kullanılan mekanizmalardandır. Kullanımında son derece dikkatli olmamız gereken bir nokta vardır. Ancak o noktaya değinmeden evvel isterseniz critical section kullanımını hayalimizde canlandırmaya çalışalım.

Şimdi elektrik faturası ödemek üzere evinize en yakın elektrik idaresine gittiğinizi düşünün. Elektrik idaresinde faturanızı yatırabilmeniz maksadı ile 10 memur çalışıyor olsun.
Her bir memurun kendisine ait de bir odası olsun. Bu odalara 1′den 10′a kadar numara verdiğimizi düşünelim. Memurlar, bir seferde sadece bir aboneyi odaya kabul etsinler ve bir kişinin faturası ile ilgilensinler. Bir abone faturasını yatırmak için memurun bulunduğu odaya girdiğinde oda kapısının müstahdem(hademe) tarafından kapatıldığını ve başkalarının odaya girmesine müstahdemin izin vermediğini düşünelim. Böyle bir sistemde bir oda içinde aynı anda birden fazla elektrik abonesi bulunamaz. Bir abonenin içeride olduğunu bilen müstahdem kapıdan içeri girmeye çalışacak olan bir diğer aboneyi beklemesi hususunda uyaracaktır.

Bu örneğimizde oda; güvenle çalışmasını istediğimiz koddur. Müstahdem işletim sistemidir. Oda kapısı ise critical section’dır. Tıpkı bu örnekte olduğu gibi, critical section’lar bir flag gibi çalışır. Açık yada kapalı bayrakları vardır. Bir oda kapısı ya açıktır yada kapalıdır mantığı critical section’lar içinde geçerlidir. Oda kapısının açık/kapalı olma durumuna göre odaya yeni bir abone alımından sorumlu olan müstahdem programlama dünyasında işletim sistemidir. İşletim sistemi, bir critical section ile işaretlenmiş olan kod bloğuna müstahdemlik yaparak koruma sağlayacak ve aynı kod bloğuna başka thread’lerin girmesine izin vermeyecektir.

EnterCriticalSection kapının kapandığı durumdur. Kapı bir kere kapandıktan sonra ancak LeaveCriticalSection ile açık duruma geçebilir. Daha teknik tabirler ile ifade etmek icap ederse; EnterCriticalSection işletim sistemi içerisinde bir değişkenin değerini set eder. Bir başka thread EnterCriticalSection kod bloğuna geldiğinde bu değişkenin değerinin ne olduğuna bakar. Eğer set edilmiş ise(yani kapı kapalı ise) o zaman beklemeye başlar. LeaveCriticalSection ise, set edilmiş olan işletim sistemine has değişkeni tekrar eski haline alır. Bu durumda beklemekte olan diğer thread zaman kaybetmeden içeri girer ve sistem bu şekilde işlemeye devam eder.

Delphi’de yukarıda tanımlarını verdiğimiz critical section metodlarını kullanmak için TRTLCriticalSection türünden bir yapıya ihtiyaç duyuyorduk. İşte bu yapının tanımlandığı yer ile ilgili programcılar büyük hatalara düşmektedirler. Bu hataların neler olduğunu örnek bir kod ile göstermek isterim:

TMyThread = class(TThread)
private
  Section 		: TRTLCriticalSection;

  fName,
  fStartValue,
  fStopValue	: String;
protected
  procedure Execute; override;
public
  constructor Create(const AName : String);
  destructor Destroy; override;

  property StartValue : String read fStartValue;
  property StopValue 	: String read fStopValue;
  property Name		: String read fName;
end;

implementation

{$R *.dfm}

{ TMyThread }

constructor TMyThread.Create(const AName : String);
begin
  inherited Create(true);
  FreeOnTerminate := true;
  fName := AName;

  InitializeCriticalSection(Section);

  Resume;
end;

destructor TMyThread.Destroy;
begin
  DeleteCriticalSection(Section);
  form1.Memo1.Lines.Add('Name:' + Name + ' Start Time:' + StartValue + ' Stop Time:' + StopValue);

  inherited;
end;

procedure TMyThread.Execute;
var
  iCounter : Integer;
begin
  inherited;

  EnterCriticalSection(Section);
  fStartValue := TimeToStr(Time);

  Sleep(10000);

  fStopValue  := TimeToStr(Time);
  LeaveCriticalSection(Section);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  mThread1,
  mThread2 : TMyThread;
begin
  mThread1 := TMyThread.Create('Birinci Thread');
  Sleep(2000);
  mThread2 := TMyThread.Create('İkinci Thread');
end;

Yukarıdaki kod örneğinde, Section isminde bir TRTLCriticalSection değişkenimiz var ve bu değişken TMyThread sınıfının bir üyesi olarak tanımlanmış. TMyThread’in Execute kodunda critical section’a girdiğimizi EnterCriticalSection metodu vasıtası ile söylemiş oluyoruz. Hemen ardından TimeToStr ile o anki zaman bilgisini bir değişkende depoluyoruz. Ardından 10 saniye bekliyoruz ve yeni zaman bilgisini bir başka değişkende depoluyoruz. Nihayet, LeaveCriticalSection metodunu çağırıyoruz ve kritik kod bloğundan çıktığımızı söylüyoruz.

Şimdi dikkatinizi Button’un altındaki koda verin. Burada aynı thread sınıfından iki değişken tanımlanmış ve birincisi oluşturulup otomatikman çalıştırılır çalıştırılmaz(Resume çağrısı bir thread’i başlatır), 2 saniyelik bir bekleme yapılmış ve ardından diğer thread oluşturulmuş ve çalıştırılmıştır.

Burada beklentilerimizin ne olduğu öncelikle bir yazalım ardından sonucu birlikte irdeleyelim.

Beklentimiz:

Critical section’ların çalışma mekanizmalarını tekrar hatırlayacak olursanız, bir thread’in kritik kod bloğuna girmesi bir başka threadin orada beklemesine neden oluyordu. Bizim örneğimizde “Birinci Thread” koda 02:40:00 ‘da girdiğinde “İkinci Thread” aynı kod bloğuna 02:42:00 ‘da girmeye çalışacak ancak orada bir başka thread olduğu için giremeyecektir. “İkinci Thread” imiz ancak 02:40:10′da içeriye girecektir.

Critical Section’ların doğası gereği olması gereken budur. Ancak bu örnekte beklediğimizi bulamayacağız. Çalıştırıp sonuçlarına bir bakalım:

Sonuç

Sizinde gördüğünüz gibi “İkinci Thread” birincisini beklemeden içeriye girebilmiştir. Peki bu nasıl oldu ? Onca yazdığımız şey doğru değilmiydi ?

Elbetteki doğru idi. Ancak burada programcıların %95′inin yaptığı bir hatayı simüle ettik. TRTLCriticalSection türündeki ve “Section” ismindeki değişken TMyThread’in bir üye değişkenidir. Ve bu üye değişkene TMyThread sınıfı oluşturulduğunda hafızada bir yer ayırılmaktadır. TMyThread sınıfının oluşturulan her bir instance’ı için Section değişkeninin hafızadaki adresi farklı bir yeri gösterecektir.

Tekrar elektrik idaresi örneğine dönecek olursak; “Birinci Thread” için Section 5 numaralı odayı, “İkinci Thread” için ise 10 numaralı odayı gösteriyor olabilir. Böylece; “Birinci Thread” 5 numaralı odanın kapısını açmış ve içeri girmiş; “İkinci Thread” ise 10 numaralı odanın içinde kimse olmadığı için o da 10 numaralı odaya girebilmiştir.

Buradan anlaşılması gereken özet bilgi şudur: critical section’ları işaret eden değişkeni bir thread’in yerel değişkeni yaparsanız, hiç bir zaman istediğinizi elde edemezsiniz. Bu yerel değişken sadece ve sadece o anda create edilmiş olan instance için anlamlıdır. Diğer thread instance’larını bağlamaz. Şimdi bu Section değişkenini global bir alana taşıyıp kodumuzu revize edelim ve test sonuçlarını burada paylaşalım:

TMyThread = class(TThread)
private
  fName,
  fStartValue,
  fStopValue	: String;
protected
  procedure Execute; override;
public
  constructor Create(const AName : String);
  destructor Destroy; override;

  property StartValue : String read fStartValue;
  property StopValue 	: String read fStopValue;
  property Name		: String read fName;
end;

var
  Form1: TForm1;
  Section	: TRTLCriticalSection;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  mThread1,
  mThread2 : TMyThread;
begin
  mThread1 := TMyThread.Create('Birinci Thread');
  Sleep(2000);
  mThread2 := TMyThread.Create('İkinci Thread');
end;

{ TMyThread }

constructor TMyThread.Create(const AName : String);
begin
  inherited Create(true);
  FreeOnTerminate := true;
  fName := AName;

  Resume;
end;

destructor TMyThread.Destroy;
begin
  form1.Memo1.Lines.Add('Name:' + Name + ' Start Time:' + StartValue + ' Stop Time:' + StopValue);

  inherited;
end;

procedure TMyThread.Execute;
var
  iCounter : Integer;
begin
  inherited;

  EnterCriticalSection(Section);
  fStartValue := TimeToStr(Time);

  Sleep(10000);

  fStopValue  := TimeToStr(Time);
  LeaveCriticalSection(Section);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  InitializeCriticalSection(Section);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  DeleteCriticalSection(Section);
end;

Kodumuzun bu yeni halinde, TMyThread sınıfının constructor’ındaki InitializeCriticalSection kaldırılmış ve formumuzun OnCreate event’ine taşınmıştır. Benzer bir şekilde, destructor’daki DeleteCriticalSection metodu formumuzun OnDestroy metoduna taşınmış ve TMyThread içinde TRTLCriticalSection türündeki değişkenimiz global alana taşınmıştır. Geri kalan kodlar bire bir aynıdır. Buyrun çalıştırma sonuçlarına birlikte bakalım:

Görüldüğü üzere “İkinci Thread” ‘imiz “Birinci Thread” işini bitirmeden kod bloğundan içeri girememiştir. Yani critical section’lardan beklenen davranış oluşmuştur. Bu husus son derece önemlidir ve pek çok programcının yaptığı ciddi thread hatalarının başında gelir. Critical section’ları Windows API’leri ile kullanmak yerine kullanımı daha kolay olan ama bire bir aynı işi yapan TCriticalSection Delphi sınıfı ile kullanabilirsiniz. TCriticalSection sınıfı SyncObjs.pas isimli dosyada tanımlanmıştır.Enter ve Leave isimli iki metoda sahiptir. Tahmin edebileceğiniz gibi, yada Delphi kaynak kodlarından gözlemleyebileceğiniz gibi bu metodlar içlerinde EnterCriticalSection ve LeaveCriticalSection metodlarını çağırmaktadırlar.

Critical Section’lar hakkında son söz olarak aşırı kullanımının performansa olumsuz etkileri olacağını belirtmek isterim. Bu sebeple, thread içindeki kodlarınızı optimize etmeli ve sadece gereken noktalarda critical section’ları kullanmalısınız. Critical Section içindeki kod bloklarınızı mümkün mertebe kısa tutmalısınız.

WaitForSingleObject & WaitForMultipleObjects

Bir sonraki senkronizasyon mekanizmamız olan mutex’ler kavramını izaha başlamadan evvel ihtiyacımız olan iki API fonksiyonuna değinmemiz gerekiyor. Bunlar WaitForSingleObject ve WaitForMultipleObjects API’leri.

Bu iki API fonksiyonu senkronizasyon mekanizmaları için son derece önemlidir. Bu fonksiyonlar beklemek amacı ile kullanılırlar. İşletim sistemindeki senkronizasyon mekanizmaları bir önceki örneğimizde bahsettiğimiz critical section’larda da olduğu gibi bir kapı şeklinde çalışırlar. Kapı ya açıktır yada kapalıdır. WaitForSingleObject ve WaitForMultipleObjects fonksiyonları kapı kapalı olduğu müddetçe beklemek amacı ile vardır.

Öncelikle tanımlarına yakından bir bakalım:

DWORD WaitForSingleObject(
  HANDLE hHandle,
  DWORD dwMilliseconds
);

DWORD WaitForMultipleObjects(
  DWORD nCount,
  CONST HANDLE *lpHandles,
  BOOL bWaitAll,
  DWORD dwMilliseconds
);

ve Delphi tanımları aşağıdaki gibidir:

  MAXIMUM_WAIT_OBJECTS = 64;

  TWOHandleArray = array[0..MAXIMUM_WAIT_OBJECTS - 1] of THandle;
  PWOHandleArray = ^TWOHandleArray;

  function WaitForSingleObject(hHandle: THandle; dwMilliseconds: DWORD): DWORD; stdcall;

  function WaitForMultipleObjects(nCount: DWORD; lpHandles: PWOHandleArray;
  bWaitAll: BOOL; dwMilliseconds: DWORD): DWORD; stdcall;

Her iki fonksiyonda bekleme yapacakları nesnelerin tutacaklarını(THandle) parametre olarak almaktadırlar. Bu fonksiyonlarla; CreateEvent yada OpenEvent, CreateMutex yada OpenMutex, CreateProcess yada OpenProcess, CreateSemaphore yada OpenSemaphore, CreateThread yada CreateRemoteThread, CreateWaitableTimer yada OpenWaitableTimer fonksiyon çağırımlarından geri dönen handle değerlerini bekleyebilirsiniz.

Yani, WaitForSingleObject yada WaitForMultipleObjects ile; bir Event’in, bir Mutex’in, bir Process’in, bir Semaphore’un, bir Thread’in yada bir Waitable Timer’ın bitmesini bekleyebilirsiniz. WaitForSingleObject’in ikinci parametresi, milisaniye cinsinden bekleme zaman bilgisidir. Tanımından da görebileceğiniz gibi, bu zaman bilgisi DWord türündedir ve DWord 32 bit bir tamsayıdır. 32 bit bir tamsayının alabileceği maksimum değer, High(DWord) = $FFFF FFFF = 4.294.967.295 ms. = 49.7 gündür. Tam bu noktada 49.7 gün ile ilgili bir diğer makalemizi incelemeniz faydalı olabilir.

Delphi’de INFINITE isimli sabit aşağıdaki şekilde tanımlanmıştır:

  INFINITE = DWORD($FFFFFFFF);

WaitForSingleObject fonksiyonunun ikinci parametresine genellikle INFINITE sabitini geçeriz. Bu da fonksiyonumuzun beklediği işletim sistemi nesnesini 49.7 gün boyunca beklemesi anlamına gelir. Hemen kısa bir örnek vererek yazdıklarımızı zihninizde pekiştirelim;

Örneğimizde bir thread oluşturacak ve bu thread’in sonlanmasını bekleyeceğiz;

TMyThread = class(TThread)
protected
  procedure Execute; override;
public
  constructor Create;
end;

var
Form1: TForm1;

implementation

{$R *.dfm}

{ TMyThread }

constructor TMyThread.Create;
begin
  inherited Create(true);
  FreeOnTerminate := true;

  Resume;
end;

procedure TMyThread.Execute;
begin
  inherited;

  Sleep(20000);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  mThread : TMyThread;
  RetVal    : DWord;
begin
  mThread := TMyThread.Create;
  RetVal := WaitForSingleObject(mThread.Handle, INFINITE);
  ShowMessage('Thread bitti');
end;

Yukarıdaki örneğimizde basit bir thread sınıfımız olduğunu görüyorsunuz. Thread’in çalışma kodunda hiç bir şey yapmadan 20 saniye bekliyoruz. Thread’i oluşturan Button1′in OnClick metodunda ise WaitForSingleObject ile thread’in bitmesini bekliyoruz. Thread’in oluşturulup çalıştırılmasından itibaren 20 saniye sonra threadimiz bitecek ve WaitForSingleObject fonksiyonunun hemen altındaki ShowMessage kodumuz çalışabilecektir. Yukarıdaki kodu biraz değiştirelim ve belirli bir zaman bekleme kodu yazalım:

procedure TForm1.Button1Click(Sender: TObject);
var
  mThread : TMyThread;
  RetVal    : DWord;
begin
  mThread := TMyThread.Create;
  RetVal := WaitForSingleObject(mThread.Handle, 10000); // 10 saniye bekle..
  ShowMessage('Thread bitti');
end;

Kodumuzun bu yeni halinde thread’in çalışma zamanında herhangi bir değişiklik yapmadık ancak bekleme kodumuzu 10 saniye olarak belirttik. Bunu yapmamızın sebebi, WaitForSingleObject metodunun dönüş değerlerini size anlatabilmek içindi. Normalde thread’lerimiz içinde 20 sn. bekle gibi bir kod yazmayız, dolayısı ile genellikle thread’lerimizin çalışma süresinin ne kadar olacağını kestiremeyiz. Yukarıdaki gibi WaitForSingleObject’e 10 saniye beklemesini söylediğimiz kullanımlarda, acaba gerçekten bu zaman zarfında thread’in bittiğini nereden bileceğiz ?

Bizim şu andaki örneğimizde thread’imiz 20 saniye sürüyordu, oysa biz 10 saniye bekledikten sonra çıktık. İşte bu sorumuza WaitForSingleObject’ten geriye dönen değerin kontrolü vasıtası ile yanıt bulabileceğiz. WaitForSingleObject yada WaitForMultipleObjects’den dönen değerler aşağıdaki gibidir:

  STATUS_WAIT_0                   = $00000000;
  STATUS_TIMEOUT                 = $00000102;

  WAIT_OBJECT_0 = ((STATUS_WAIT_0 ) + 0 );
  WAIT_TIMEOUT = STATUS_TIMEOUT;

Eğer WaitForSingleObject’in beklediği işletim sistemi nesnesinin bitmesi sebebi ile WaitForSingleObject beklemeyi bıraktı ise; bize fonksiyonun geri dönüş değeri WAIT_OBJECT_0 olacaktır. Aksi durumda, yani işletim sistemi nesnesi hâla tamamlanmamış ancak bizim belirttiğimiz bekleme zamanı dolmuş ise o zamanda WAIT_TIMEOUT değerini elde edeceğiz. Yeni kodumuz aşağıdaki gibi olacak;

procedure TForm1.Button1Click(Sender: TObject);
var
  mThread : TMyThread;
  RetVal    : DWord;
begin
  mThread := TMyThread.Create;
  RetVal := WaitForSingleObject(mThread.Handle, 10000); // 10 saniye bekle..
  case RetVal of
    WAIT_OBJECT_0 : ShowMessage('Thread tamamlanmış.');
    WAIT_TIMEOUT  : ShowMessage('Thread hâla çalışıyor ancak 10 saniye dolmuş.');
  end;
end;

Sizin de kod örneklerinden anlayabileceğiniz gibi, WaitForSingleObject yada WaitForMultipleObjects fonksiyonları bekleme yaptıkları için çağırıldıkları ortamı(thread) bloke edeceklerdir. Bizim örneğimizde WaitForSingleObject formumuzun üstündeki bir button’un altında çağırıldığına göre uygulamamızın main thread’i bloke olacaktır. 10 saniyenin geçmesine müteakip main thread’imiz yine devrede olacaktır. Tabii WaitForSingleObject fonksiyonunun ikinci parametresini INFINITE olarak geçerseniz örneğimize göre uygulamamızın main thread’i 20 saniye boyunca blok olacaktır.

Bir önceki makalemizde TThread sınıfının WaitFor isimli metodunun aynı şeyi yaptığından bahsetmiştik. Ancak o makalede de görebileceğiniz gibi, WaitFor metodu şu an sıkıntılı. Dolayısı ile yukarıda saydığımız işletim sistemi nesnelerini şimdilik WaitForSingleObject ile beklemeniz daha iyi olacaktır.

WaitForSingleObject için yazdığımız herşey WaitForMultipleObjects içinde geçerlidir. Ancak WaitForMultipleObjects’in biraz daha farklı yönleri vardır. Farzedelim ki, uygulamanız içinde birden fazla threadiniz var ve bu thread’lerin hepsinin bitmesini beklemek istiyorsunuz. Her thread için WaitForSingleObject kullanmak hiç de mantıklı olmazdı. O zaman imdadınıza WaitForMultipleObjects yetişecek. Bir önceki örneğimizi birden fazla thread’e göre yeniden yazalım ve bu sefer WaitForMultipleObjects kullanalım:

TMyOtherThread = class(TThread)
private
  fSecond : DWord;
protected
  procedure Execute; override;
public
  constructor Create(const Second : DWord);
end;

{ TMyOtherThread }

constructor TMyOtherThread.Create(const Second : DWord);
begin
  inherited Create(true);
  FreeOnTerminate := true;
  fSecond := Second;

  Resume;
end;

procedure TMyOtherThread.Execute;
begin
  inherited;

  Sleep(fSecond * 1000);
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  mThread1,
  mThread2,
  mThread3,
  mThread4 : TMyOtherThread;

  Handles    : array[0..3] of THandle;

  StartTime,
  StopTime  : String;
  RetVal    : DWord;
begin
  StartTime := TimeToStr(Time);

  mThread1 := TMyOtherThread.Create(15);
  Handles[0] := mThread1.Handle;

  mThread2 := TMyOtherThread.Create(10);
  Handles[1] := mThread2.Handle;

  mThread3 := TMyOtherThread.Create(20);
  Handles[2] := mThread3.Handle;

  mThread4 := TMyOtherThread.Create(25);
  Handles[3] := mThread4.Handle;

  RetVal := WaitForMultipleObjects(4, @Handles, true, INFINITE);

  case RetVal of
    WAIT_OBJECT_0 	: Memo1.Lines.Add('Thread 0 tamamlandı.');
    WAIT_OBJECT_0 + 1	: Memo1.Lines.Add('Thread 1 tamamlandı.');
    WAIT_OBJECT_0 + 2	: Memo1.Lines.Add('Thread 2 tamamlandı.');
    WAIT_OBJECT_0 + 3	: Memo1.Lines.Add('Thread 3 tamamlandı.');
  end;

  StopTime := TimeToStr(Time);

  Memo1.Lines.Add('Start Time:' + StartTime + '-Stop Time:' + StopTime);
  Memo1.Lines.Add(InttoStr(RetVal));
end;

Yukarıdaki örneğimizde, 4 adet TMyOtherThread oluşturuluyor. Birinci thread 15 sn. , ikinci thread 10 sn. , üçüncü thread 20 sn. ve son thread ise 25 sn. çalışacak şekilde ayarlanıyor. Ardından WaitForMultipleObjects fonksiyonumuza 4 adet thread’i beklemesi gerektiği ve bu thread’lerin handle’larının Handles isimli array tipli değişkende olduğu söyleniyor. Fonksiyonun üçüncü parametresi bütün thread’lerin beklenip beklenmeyeceğini ifade ediyor. Biz bu parametreye true geçerek tüm thread’lerin beklenmesini istediğimizi söylüyoruz. Dördüncü ve son parametre ne kadar süre ile beklememiz gerektiği bilgisini içeriyor. Bu parametreye INFINITE girerek tüm thread’lerin bitmesine yetecek kadar zaman beklememiz gerektiğini ifade etmiş oluyoruz.

Bu durumda, TMemo türündeki Memo1 nesnemizde iki zaman aralığının 25 saniye olduğunu göreceksiniz. Çünkü, en uzun zaman çalışan thread 25 saniye sürüyor. Tüm thread’leri bekleyeceğimizi söylediğimiz içinde bekleyeceğimiz süre en uzun süre çalışan thread’in çalışma süresi kadar yani 25 saniye olmuş oluyor.

Yukarıdaki örneğimizde WaitForMultipleObjects fonksiyonundan geriye dönen değeri sakladığımız RetVal isimli değişkenin değerini bir case ifadesinde kontrol ettiğimizi göreceksiniz. WaitForMultipleObjects fonksiyonu tüm thread’lerin bekleneceğini anlatan üçüncü parametresine true geçilmesi durumunda her zaman tüm thread’lerin bitmesini bekleyeceği için geriye WAIT_OBJECT_0 döndürecektir.(Son parametrenin INFINITE olması halinde, aksi durumda belirtilen zaman yeterli gelmez ise WAIT_TIMEOUT döndürür.)

Peki tüm thread’lerin bitmesini beklemez isek ne olur ? Bu durumda WaitForMultipleObjects fonksiyonunun üçüncü parametresine false geçmemiz gerekir. Bunu yaptığımızda, çalışma süresi en kısa olan thread işini bitirdiğinde WaitForMultipleObjects artık beklemekten vazgeçecektir. Geriye dönen değer ise biten thread’in dizideki indis numarası olacaktır. Yukarıdaki örneğimizde;

Çalışma süresi en az olan thread “Thread 2″ olacağından WaitForMultipleObjects bize WAIT_OBJECT_0 + 1 döndürecektir. Bu mekanizma vasıtası ile birden fazla işletim sistemi nesnesinin beklendiği durumda hangi nesnenin sonlandığını bulabilirsiniz.

Mutex

Critical Section’lardan sonra bu mekanizmaya son derece benzeyen Mutex’lere giriş yapabiliriz. Mutex’ler tüm senkronizasyon mekanizmalarında olduğu gibi kod bloklarımızı birden fazla thread’in girmesi vesilesi ile oluşabilecek bozulmalardan korurlar. Aynı amaca critical section’larında hizmet ettiğini söylemiştik. Peki mutex’ler de aynı şeyi yapıyor ise neden varlar ?

Aslında mutex’ler bire bir critical section’ların yaptıklarını yaparlar. Ancak fazladan güzel özelliklere sahiptirler. Bu özellikleri anlatmaya geçmeden evvel herzamanki gibi C++ ve Delphi tanımlarımıza yakından bakalım:

HANDLE CreateMutex(
  LPSECURITY_ATTRIBUTES lpMutexAttributes,
  BOOL bInitialOwner,
  LPCTSTR lpName
);

HANDLE OpenMutex(
  DWORD dwDesiredAccess,
  BOOL bInheritHandle,
  LPCTSTR lpName
);

BOOL ReleaseMutex(
  HANDLE hMutex
);

ve Delphi tanımları:

  function CreateMutex(lpMutexAttributes: PSecurityAttributes; bInitialOwner: BOOL; lpName: PChar): THandle; stdcall;
  function OpenMutex(dwDesiredAccess: DWORD; bInheritHandle: BOOL; lpName: PChar): THandle; stdcall;
  function ReleaseMutex(hMutex: THandle): BOOL; stdcall;

Bir mutex senkronizasyon nesnesi CreateMutex API’si ile oluşturulur ve CloseHandle API’si ile de işletim sisteminden silinir. Mutex’lerin critical section’lara son derece benzediğini söylemiştik. Hatırlarsanız critical section’larda InitializeCriticalSection, DeleteCriticalSection, EnterCriticalSection ve LeaveCriticalSection metodlarını kullanıyorduk. Mutex ve critical section fonksiyonlarının benzerlikleri aşağıdaki tablodan gözlemlenebilir:

Tüm bu bilgilerin ışığında bir critical section’un yaptığı işi mutex ile yapan bir örneği inceleyebiliriz;

type
TMutexThread = class(TThread)
private
  fName,
  fStartValue,
  fStopValue	: String;
protected
  procedure Execute; override;
public
  constructor Create(const AName : String);
  destructor Destroy; override;

  property StartValue : String read fStartValue;
  property StopValue 	: String read fStopValue;
  property Name		: String read fName;
end;

var
  Form1: TForm1;
  MutexHandle   : THandle;

implementation

procedure TForm1.FormCreate(Sender: TObject);
begin
  MutexHandle := CreateMutex(nil, false, nil);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  CloseHandle(MutexHandle);
end;

{ TMutexThread }
constructor TMutexThread.Create(const AName: String);
begin
  inherited Create(true);
  FreeOnTerminate := true;

  fName := AName;

  Resume;
end;

destructor TMutexThread.Destroy;
begin
  form1.Memo1.Lines.Add('Mutex Name:' + Name + ' Start Time:' + StartValue + ' Stop Time:' + StopValue);

  inherited;
end;

procedure TMutexThread.Execute;
begin
  inherited;

  WaitForSingleObject(MutexHandle, INFINITE);
  fStartValue := TimeToStr(Time);

  Sleep(10000);

  fStopValue := TimeToStr(Time);
  ReleaseMutex(MutexHandle);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  mMutex1,
  mMutex2 : TMutexThread;
begin
  mMutex1 := TMutexThread.Create('Birinci Mutex');
  Sleep(2000); // 2 sn bekle..
  mMutex2 := TMutexThread.Create('İkinci Mutex');
end;

Yukarıdaki örneğimiz tıpkı critical section örneğindeki gibi çalışacaktır. “Birinci Mutex” çalışmasına başlayacak ve WaitForSingleObject ile global MutexHandle değişkeni vasıtası ile kapının açık olup olmadığını sorgulayacak ve kapı açık olduğundan hemen koda girecektir. “İkinci Mutex” 2 saniye sonra birincisi gibi korumalı koda girmeye çalışacak ama kapı kapalı olduğu için beklemeye başlayacaktır. “Birinci Mutex” thread’i ReleaseMutex çağrısı yapar yapmaz “İkinci Mutex” thread’i korumalı koda girebilecektir. Örnek uygulamamızın çıktısı:

biçiminde olacaktır. Görüldüğü gibi “İkinci Mutex” birincisini beklemiş ve ardından çalışmaya devam etmiştir.

Bu noktaya kadar mutex’lerin critical section’lardan bir farkı görünmüyor. O halde neden mutex kullanacağız ? Mutex’lerin esas gücü, senkronizasyon mekanizmasını process’ler arasında da yapabilmesinden geliyor. CreateMutex tanımını hatırlayacak olursanız, 3ncü ve son parametresinde bir isim alabildiğini gözlemleyeceksiniz. Bu parametreye geçerli bir isim verilir ise, mutex’ler işletim sistemi üzerindeki birden fazla process arasında senkronizasyon yapabilme yeteneğine kavuşur.

Bazı zamanlarda thread ile erişeceğimiz kritik kodlar, işletim sistemi üzerindeki bazı kaynaklara tekil erişim gerektirirler. Örneğin; makinanıza programlanabilme imkanına sahip bir donanımın bağlı olduğunu düşünelim. Bu herhangi bir donanım olabilir. Diyelim ki, bir modeminiz var ve siz bu modemin BIOS’unu güncelleyebilen bir program yazdınız. Modem’in BIOS’u güncelleme işlemi sürer iken bir başka güncelleme isteğinin modem’e yönlendirilmemesi gerekir. Yazdığınız uygulamanın derlenmiş halinin ModemBIOS.exe olduğu düşünüldüğünde, bu uygulamanın içinde Modem’e erişip BIOS’u güncelleyen kodun bir daha çalıştırılmamasını sağlayabilirsiniz. Ancak sizin uygulamanızı kullanan kullanıcının ModemBIOS.exe programını bir tane daha açması durumunda ne olur ?

Bu durumda ModemBIOS.exe process’inden o anda çalışan iki adet olur. Ve her bir process kendi hafıza alanına sahip olduğu için , process’ler birbirlerinin kritik kod bloklarını bilemezler. Bu gibi bir durumda, ikinci ModemBIOS.exe uygulamanızda modem’in BIOS’unu güncellemeye çalışabilir ve geri dönülmesi zor donanımsal hatalara neden olabilirsiniz.

İşte tam bu noktada mutex’lerin gücü devreye girer. Birinci uygulamanın mutex’i oluşturduğunu ve modem’in bios’unu kritik kod bloğunda güncellediğini düşünelim. İkinci uygulama artık CreateMutex ile değil, OpenMutex ile mutex’e verilen isim vasıtası ile mutex’i açmaya çalışır. Bu durumda elde edilecek mutex handle’ı birinci uygulamanın create ettiği handle olacaktır.! Elde edilen bu handle ile BIOS’u güncelleyecek olan kod bloğuna girmeye çalışacak olan ikinci uygulamamız ; birinci uygulama o kod bloğundan çıkmadan içeriye giremeyecektir. Bu durumu simüle eden bir örnek yapalım arzu ederseniz;

type
TMutexThread = class(TThread)
private
  fName,
  fStartValue,
  fStopValue	: String;
protected
  procedure Execute; override;
public
  constructor Create(const AName : String);
  destructor Destroy; override;

  property StartValue : String read fStartValue;
  property StopValue 	: String read fStopValue;
  property Name		: String read fName;
end;

var
  Form1: TForm1;
  MutexHandle   : THandle;
implementation

{ TMutexThread }
constructor TMutexThread.Create(const AName: String);
begin
  inherited Create(true);
  FreeOnTerminate := true;

  fName := AName;

  Resume;
end;

destructor TMutexThread.Destroy;
begin
  form1.Memo1.Lines.Add('Mutex Name:' + Name + ' Start Time:' + StartValue + ' Stop Time:' + StopValue);

  inherited;
end;

procedure TMutexThread.Execute;
begin
  inherited;

  WaitForSingleObject(MutexHandle, INFINITE);
  fStartValue := TimeToStr(Time);

  Sleep(10000);

  fStopValue := TimeToStr(Time);
  ReleaseMutex(MutexHandle);
end;

procedure TForm1.FormCreate(Sender: TObject);
var
  Error : DWord;
begin
  MutexHandle := OpenMutex(MUTEX_ALL_ACCESS, false, PAnsiChar('Modem BIOS'));
  if MutexHandle = 0 then
  begin
    Memo1.Lines.Add('Mutex bulunamadı, oluşturulacak.');
    MutexHandle := CreateMutex(nil, false, PAnsiChar('Modem BIOS'));
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
      Memo1.Lines.Add('Modem BIOS ismi daha önce mutex harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end
  else Memo1.Lines.Add('Mutex bulundu ve OpenMutex ile açıldı.');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  CloseHandle(MutexHandle);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  mMutex1,
  mMutex2 : TMutexThread;
begin
  Label1.Caption := 'Başlangıç Zamanı:' + TimeToStr(Time);
  mMutex1 := TMutexThread.Create(Edit1.Text);
  Sleep(2000); // 2 sn bekle..
  mMutex2 := TMutexThread.Create(Edit2.Text);
end;

Yukarıdaki örneğimizde, button1′in OnClick olay yöneticisinde iki adet thread çalıştırılıyor. Bu thread’ler mutex senkronizasyon nesnelerini kullanıyorlar. Bu uygulama birden fazla sefer çalıştırıldığında ve ilgili button’a basıldığında çalışacak olan kodlar birbirlerini bekleyeceklerdir. Mutex’leri critical section’lardan farklı kılan en önemli özellik budur. Çalışacak olan thread’ler hangi process’de olurlarsa olsunlar aynı anda sadece bir tanesinin çalışmasını sağlamış olduk.

Formumuzun OnCreate olayında “Modem BIOS” olarak isimlendirdiğimiz bir mutex’i OpenMutex API’si vasıtası ile açmaya çalışıyoruz. Eğer bu isimde bir mutex daha önce oluşturuldu ise, OpenMutex fonksiyonu oluşturulan mutex’in handle’ını döndürür aksi durumda sıfır döndürecektir. Process’ler arası senkronizasyonun en can alıcı noktası da burasıdır. Mutex’lerin bu özelliği aynı zamanda sıklıkla; çalıştırılan uygulamanın birden fazla örneğinin olmaması için de kullanılmaktadır.

Eğer OpenMutex daha önce oluşturulmuş bir mutex bulamaz ise, o zaman mutex’i CreateMutex API’si vasıtası ile oluşturma yoluna gidiyoruz. CreateMutex fonksiyonunundan hemen sonra işletim sistemi fonksiyonlarından olan GetLastError ile son hata durumunu kontrol ediyoruz. CreateMutex API’si, kendisine geçilen isim ile(örneğimizde “Modem BIOS”) daha önce oluşturulmuş mutex harici bir nesne var(event, semaphor gibi) ise ERROR_INVALID_HANDLE değerini döndürecektir. Çünkü, event, semaphor, mutex gibi senkronizasyon nesneleri aynı isimlendirme alanını ortak kullanırlar.

Mutex’imizi formumuzun OnCreate olayında açtıktan yada oluşturduktan sonra mutex senkronizasyon nesneleri ile korumaya alınmış thread kodlarımızın çalıştırılmasını sağlıyoruz. Aşağıda yayınlayacağımız video’dan da görebileceğiniz gibi; birden fazla aynı uygulama çalıştırıldığında button’lara basma sırasına göre thread’ler sıraya girecekler ve hangi uygulamadan çalıştırıldıklarından bağımsız olarak birbirlerini bekleyebileceklerdir.

Semaphore

Mutex senkronizasyon nesnelerinden sonra semaphore’lar hakkında da biraz konuşmamız gerekir. Bazen kritik olduğunu düşündüğümüz kod bloklarımıza sadece bir thread’in değil bizim belirlediğimiz sayıda thread’in girebilmesini de isteriz. Semaphore’ler bu amaca hizmet eden senkronizasyon mekanizmalarıdır. Semaphore’ler da tıpkı mutex’lerde olduğu gibi bir isimle yada isimsiz olarak oluşturulabilirler. İsimle oluşturulduklarında tahmin edeceğiniz üzere, birden fazla process’in birden fazla thread’ini sorunsuz bir şekilde senkronize edebilirler. Gelin herzamanki gibi önce tanımlarına bir göz gezdirelim:

HANDLE CreateSemaphore(
  LPSECURITY_ATTRIBUTES lpSemaphoreAttributes,
  LONG lInitialCount,
  LONG lMaximumCount,
  LPCTSTR lpName
);

HANDLE OpenSemaphore(
  DWORD dwDesiredAccess,
  BOOL bInheritHandle,
  LPCTSTR lpName
);

BOOL ReleaseSemaphore(
  HANDLE hSemaphore,
  LONG lReleaseCount,
  LPLONG lpPreviousCount
);

  function CreateSemaphore(lpSemaphoreAttributes: PSecurityAttributes;
  lInitialCount, lMaximumCount: Longint; lpName: PChar): THandle; stdcall;

  function OpenSemaphore(dwDesiredAccess: DWORD; bInheritHandle: BOOL; lpName: PChar): THandle; stdcall;

  function ReleaseSemaphore(hSemaphore: THandle; lReleaseCount: Longint;
  lpPreviousCount: Pointer): BOOL; stdcall;

Bir semaphore nesnesi, tıpkı mutexlerde olduğu gibi CreateSemaphore ile oluşturulur ve CloseHandle ile işletim sisteminden silinir. Mutex’lerde olduğu gibi semaphore’lar da da WaitForSingleObject kritik kod bloğunun başında yer alır. Kritik kod bloğu ReleaseSemaphore ile sonlandırılır. Semaphore nesnelerinin en önemli özelliğinin bir sayaç mekanizmasına sahip olduğunu ifade etmiştik. CreateSemaphore fonksiyonunun ikinci ve üçüncü parametreleri son derece önemlidir. İkinci parametre semaphore sayacının başlangıç değerini, üçüncü parametre ise kritik koda girebilecek maksimum thread sayısını ifade eder. Bu parametrelerin sahip olabilecekleri değerlere ilişkin kurallar aşağıda belirtildiği gibidir.

  lInitialCount >= 0 veya lInitialCount <= lMaximumCount
  lMaximumCount > 0

Her WaitForSingleObject çağrısı semaphore mekanizmasında sayacın bir azaltılmasını sağlar ve yine her ReleaseSemaphore çağrısı sayacın bir arttırılmasına neden olur.Örneğin;

var
  SemaphoreHandle : THandle;
begin
  SemaphoreHandle := CreateSemaphore(nil, 2, 2, PAnsiChar('Semaphore Test')); // Sayaç değeri 2'dir.

  WaitForSingleObject(SemaphoreHandle, INFINITE); // Sayaç değeri 1'e iner.
  ..
  ..
  ReleaseSemaphore(SemaphoreHandle, 1, nil); // Sayaç değeri yeniden 2'ye çıkar.
end;

Yukarıda gördüğünüz basit yapıda olduğu gibi bir semaphore sizin belirttiğiniz sayaç değeri ile başlar ve her WaitForSingleObject gördüğünde bu sayaç değeribi bir azaltır. Sayaç değeri sıfıra ulaştığında içeri girmeye çalışacak olan thread’ler bekletilmeye başlanır. Bu sayede kritik kod bloğuna sizin belirttiğiniz sayıda thread’in girmesi sağlanmış olur. Her ReleaseSemaphore çağrısı sayacı 1 arttıracaktır. Sayaç sıfırdan farklı bir değere ulaşır ulaşmaz, beklemekte olan thread’lerden bir tanesi hemen kritik kod bloğuna girecektir. Semaphore’larla ilgili kod örneğine geçmeden önce, OpenSemaphore fonksiyonunun birinci parametresindeki erişim sabitlerinin Delphi 7′de tanımlanmamış olduğunu hatırlatmakta fayda görüyorum. Delphi 2009′dan aldığım sabit tanımın Delphi 7 kullanan arkadaşlarımız için faydalı olacağına inanıyorum;

  SEMAPHORE_ALL_ACCESS = (STANDARD_RIGHTS_REQUIRED or SYNCHRONIZE or $3);

Şimdi isterseniz, sayaç mekanizması vasıtası ile kritik kod bloklarını senkronize eden semaphore’ler ile ilgili basit bir örnek yapalım. Bu örnek mutex’lerle son derece benzer olacak;

type
TSemaphoreThread = class(TThread)
private
  fName,
  fStartValue,
  fStopValue	: String;
protected
  procedure Execute; override;
public
  constructor Create(const AName : String);
  destructor Destroy; override;

  property StartValue : String read fStartValue;
  property StopValue 	: String read fStopValue;
  property Name		: String read fName;
end;

var
  Form1: TForm1;
  SemaphoreHandle : THandle;

implementation

procedure TForm1.FormCreate(Sender: TObject);
const
  SEMAPHORE_ALL_ACCESS = (STANDARD_RIGHTS_REQUIRED or SYNCHRONIZE or $3);
var
  Error : DWord;
begin
  SemaphoreHandle := OpenSemaphore(SEMAPHORE_ALL_ACCESS, false, PAnsiChar('Semaphore Test'));
  if SemaphoreHandle = 0 then
  begin
    Memo1.Lines.Add('Semaphore bulunamadı, oluşturulacak.');
    SemaphoreHandle := CreateSemaphore(nil, 2, 2, PAnsiChar('Semaphore Test'));
    Error := GetLastError();

    if Error = ERROR_INVALID_HANDLE then
      Memo1.Lines.Add('Semaphore Test ismi daha önce semaphore harici başka bir senkronizasyon nesnesinde kullanılmış.!');
  end else Memo1.Lines.Add('Semaphore bulundu ve OpenSemaphore ile açıldı.');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  CloseHandle(SemaphoreHandle);
end;

{ TSemaphoreThread }

constructor TSemaphoreThread.Create(const AName: String);
begin
  inherited Create(true);
  FreeOnTerminate := true;

  fName := AName;

  Resume;
end;

destructor TSemaphoreThread.Destroy;
begin
  form1.Memo1.Lines.Add('Semaphore Name:' + Name + ' Start Time:' + StartValue + ' Stop Time:' + StopValue);

  inherited;
end;

procedure TSemaphoreThread.Execute;
begin
  inherited;

  WaitForSingleObject(SemaphoreHandle, INFINITE);
  fStartValue := TimeToStr(Time);

  Sleep(10000);

  fStopValue := TimeToStr(Time);
  ReleaseSemaphore(SemaphoreHandle, 1, nil);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  mThread1,
  mThread2,
  mThread3,
  mThread4	: TSemaphoreThread;
begin
  mThread1 := TSemaphoreThread.Create('Semaphore 1');
  Sleep(1000);

  mThread2 := TSemaphoreThread.Create('Semaphore 2');
  Sleep(1000);

  mThread3 := TSemaphoreThread.Create('Semaphore 3');
  Sleep(1000);

  mThread4 := TSemaphoreThread.Create('Semaphore 4');
end;

Yukarıdaki kod örneğimiz, 4 adet thread oluşturup çalıştırılmasını sağlıyor. Semaphore’umuz kritik kod bloğuna 2 adet thread’in girebileceği bilgisi ile oluşturulmuş durumda olduğu için aynı anda kritik kod bloğunda maksimum 2 thread’imiz olabilecektir. Diğer iki thread, kritik kod bloğuna giren thread’lerden dışarı çıkan olmadığı müddetçe bekleyeceklerdir.Kritik kod bloğundan bir thread çıkar çıkmaz bekleyen thread’lerden birisi hemen içeri girebilecektir. Semaphore’larda da isimlendirme özelliği olduğu için çalışan thread’lerin hangi process’de çalıştıklarının bir önemi yoktur. Bu teknikte process’ler arası senkronizasyon sayaç mekanizması ile sağlanmış olur.

Bundan sonraki hedefimizin Event ve Waitable Timer’lar olduğunu söyleyerek bu makaleyi neticelendirmek istiyorum müsaadeniz ile. Son derece uzun olduğu kanaatindeyim, dolayısı ile makaleyi daha da uzatmamak ve okunurluğu arttırabilmek adına diğer senkronizasyon mekanizmalarını bir sonraki makaleme taşıyacağım.

Bu makalemizde aslında thread konusunun basit bir konu olmadığı, ancak korkulara da yer olmadığını umarım anlatabilmişimdir. Thread’lerin diğer kodlama tekniklerinden tek farkı benim bakış açıma göre, sadece daha dikkatle kodlanmalarının zorunluluğu ve biraz işletim sistemi bilgisinin gerekliliğidir.

Sizlere bol multi-threaded’lı günler dilerim

Saygılar, sevgiler..

Kısaca sorunun ne olduğundan bahsettikten sonra, mail yazışmalarımızı ilgilenenler için paylaşacağım. Bildiğiniz gibi TThread sınıfının WaitFor metodu bir thread’in işinin bitmesini beklemek için tasarlanmıştır. Ve görevini layıkı ile yerine getirir. Ancak, eğer thread kendi constructor’ında işi bittikten sonra yok edilsin ayarına set edildi ise o zaman bu bug ile karşılaşacaksınız. Thread’inizin constructor ‘ında FreeOnTerminate := true gibi bir satır kod yazdı iseniz ve thread’inizin bitmesini WaitFor ile bekliyorsanız, thread’inizin bitmesine müteakip hata ile karşılaşacaksınız. Bunun nedeni, Thread sınıfının destructor’ında işletim sistemi tarafından ayrılmış olan thread handle’ının CloseHandle ile serbest bırakılmasına karşılık WaitFor metodu içinde bu handle’ın kullanılmaya çalışılmasıdır. Sizlere bu sorun düzeltilinceye kadarki tavsiyem WaitForSingleObject(myThread.Handle, INFINITE) kodu ile bekleme yapmanızdır.

Delphi ürün müdürü ile yazışmalarımız aşağıdaki gibidir:

FW: TThread.WaitFor Bug.!‏
From: Nick Hodges (Nick.Hodges@embarcadero.com)
Sent: Wed 6/24/09 6:13 PM
To: king_of_delphi@hotmail.com (king_of_delphi@hotmail.com)
Thanks for the report!

From: Jason Sprenger
Sent: Wednesday, June 24, 2009 11:04
To: Seppy Bloom; Nick Hodges; Jason Vokes
Cc: Thom Gerdes; Marty Thompson
Subject: RE: TThread.WaitFor Bug.!

I’ve reviewed the bug report and attached to it a test case from the original program fragments.

–Jason

From: Seppy Bloom
Sent: Monday, June 22, 2009 10:24 PM
To: Nick Hodges; Jason Vokes
Cc: Thom Gerdes; Marty Thompson; Jason Sprenger
Subject: RE: TThread.WaitFor Bug.!

Raid #270371, so we can all track it’s progress.

Seppy

From: Nick Hodges
Sent: Monday, June 22, 2009 10:52 AM
To: Seppy Bloom; Jason Vokes
Cc: Thom Gerdes; Marty Thompson; Jason Sprenger
Subject: RE: TThread.WaitFor Bug.!

Yes, here in this email.

From: Seppy Bloom
Sent: Monday, June 22, 2009 10:02
To: Nick Hodges; Jason Vokes
Cc: Thom Gerdes; Marty Thompson; Jason Sprenger
Subject: RE: TThread.WaitFor Bug.!

Is it reported somewhere?

Seppy

From: Nick Hodges
Sent: Monday, June 22, 2009 9:43 AM
To: Jason Vokes
Cc: Seppy Bloom; Thom Gerdes; Marty Thompson
Subject: FW: TThread.WaitFor Bug.!

Is there a bug here, folks?

Nick

From: Excellent Delphi [mailto:king_of_delphi@hotmail.com]
Sent: Monday, June 22, 2009 05:27
To: nick.hodges@borland.com; Nick Hodges
Subject: TThread.WaitFor Bug.!

Hi Nick, sorry about this e-mail. I dont know where the new quality central is.

Pls check the TThread.WaitFor method.

TMyThread = class(TThread)
protected
procedure Execute; override;
public
constructor Create;
end;

….
….
procedure TMyThread.Execute;
var
iCounter : Integer;
sVal : String;
begin
inherited;

for iCounter := 0 to 1000000 do sVal := InttoStr(iCounter);
end;

constructor TMyThread.Create;
begin
inherited Create(true);
FreeOnTerminate := true; // it will be a problem when u use waitfor for waiting thread’s termination
end;

procedure TForm1.Button1Click(Sender : TObject);
var
mThread : TMyThread;
begin
mThread := TMyThread.Creat e;
mThread.Resume;
mThread.WaitFor; // when we use WaitForSingleObject(mThread.Handle, INFINITE) the problem never been seen,
// because GetExitCodeThread dont called.

Caption := TimeToStr(Time);
end;

In classes.pas ThreadProc method is following;

function ThreadProc(Thread: TThread): Integer;
var
FreeThread: Boolean;
begin
{$IFDEF LINUX}
if Thread.FSuspended then sem_wait(Thread.FCreateSuspendedSem);
{$ENDIF}
try
if not Thread.Terminated then
try
Thread.Execute;
except
Thread.FFatalException := AcquireExceptionObject;
end;
fina lly
FreeThread := Thread.FFreeOnTerminate;
Result := Thread.FReturnValue;
Thread.DoTerminate;
Thread.FFinished := True;
SignalSyncEvent;
if FreeThread then Thread.Free;
{$IFDEF MSWINDOWS}
EndThread(Result);
{$ENDIF}
{$IFDEF LINUX}
// Directly call pthread_exit since EndThread will detach the thread causing
// the pthread_join in TThread.WaitFor to fail. Also, make sure the EndThreadProc
// is called just like EndThread would do. EndThreadProc should not return
// and call pthread_exit itself.
if Assigned(EndThreadProc) then
EndThreadProc(Result);
pthread_exit(Pointer(Result));
{$ENDIF}
end;
end;

When the Thread.Free call, thread handle will be invalid by CloseHandle, but WaitFor method still waits this thread. At the end of WaitFor method, it will try to call CheckThreadError(GetExitCodeThread(H[0], Result));

But H[0] is now invalid at this point, so we will give an exception. If you write “if FreeThread then Thread.Free;” line after the EndThread(Result) line, problem will be avoid.

Note: Problem is the same Delphi 7..2009
Best Regards
Tuğrul HELVACI

Microsoft, kendi işletim sistemlerinin yeryüzündeki tüm bilgisayarlarda kullanılamayacağının farkına vardığında; Java’ya karşı bir önlem almak gerektiğini düşündü ve bu sayede veriye her ortamdan erişebilecek bir sistem planlamaya başladı. Ancak elbette Java’nın da hâla beceremediği gibi Microsoft’da platform bağımsızlığı hususunda başarılı olamadı. Zaten tasarımların gereği de bunu pek mümkün kılmıyordu. Java’da üretilen kodların bytecode’lara çevrilmesi ve JVM(Java Virtual Machine) adı verilen programlarla üzerinde çalıştığı platforma adapte edilmesindeki süreç, .Net’de de kendisine farklı isimlerle yer buldu.

.Net, ürettiği MSIL kodunu üzerinde çalıştığı platformun anlayacağı makina dili koduna ise JIT vasıtası ile çevirir. Bu tıpkı Java’nın JVM’ine benzer. Aradaki benzerlikleri saymaya kalksak emin olun sayfalarca yazı yazmamız gerekir. Benim bu makalede amacım bu iki platform bağımsız olduğunu iddia eden teknolojinin benzerliklerini ve farklılıklarını anlatmak değil. Bu bilgileri genel kültür amacı ile sunduktan sonra Delphi’nin bu teknolojiler ile iletişimi hakkında bilgi vermek ve gerçek platform bağımsız kodlamanın gelecekte Delphi ile olabileceğinin umudunu sizlerle paylaşmak.

Görüldüğü üzere gerek .Net gerekse de Java platform bağımsız native kod geliştiremiyorlar. Ürettikleri ara kodların, çeşitli işletim sistemlerinde yorumlanıp makina koduna çevrilmeleri gerekiyor. Dolayısı ile teoride bu teknolojileri kullanan uygulamaların, native uygulamalardan hızlı olması beklenmiyor.

.Net, bilindiği üzere programlama dillerinden bağımsız bir platform. Framework adı verilen kod kütüphanelerinin tüm programlama dilleri tarafından ortak bir şekilde kullanılabilmesi, CTS denilen ortak tip sınıflarının .Net içinde olması, herhangi bir .Net destekli dilin bir diğer .Net destekli dil ile iletişimini son derece sorunsuz ve kolay hale getirmekte. Büyük çaplı proje ekiplerinin pek çok programcıya sahip olduğu gerçeği göz önüne alındığında, bu ekip üyelerinin herhangi bir .Net dilini bilmesi ve bu dil ile geliştirme yapmasının projeye olumsuz bir etkisinin olmaması elbette son derece güzel bir durum.

.Net Framework adı verilen kaba tabiri ile programlama kütüphanesi, şu aşamada 3.5 versiyonunda bulunuyor. Yakın bir zamanda 4.0 versiyonunun çıkması bekleniyor. Bildiğim kadarı ile Framework’teki sınıf tasarımları .Net framework 2.0′dan sonra herhangi bir değişikliğe uğramadı. Sadece üzerine yeni yetenekler eklendi. Kısaca .Net terminolojisinden bahsettikten sonra, Delphi’nin bu terminolojiye hangi mesafede olduğu hakkında yazmak isterim.

Delphi 7 , hâla pek çok Delphi kullanıcısının kullandığı ana IDE durumunda. Bunun stabilite ve hız gibi pek çok etkenleri var. Delphi, gerçek anlamda .Net ile 8 versiyonunda buluştu. Ancak Delphi 8, Microsoft’un .Net teknolojisine ilk desteği veren ürün olduğu için hiçte stabil değildi ve Delphi severler tarafından pek de tutulmadı. Ardından Borland, .Net platformuna desteğini Delphi 2005 ile sürdürdü. Ancak kişisel tecrübelerim ile söyleyebilirim ki, o da gerektiği ölçüde stabil değildi ve pek çok sorunu vardı. .Net desteği, 2006 ve 2007 sürümlerine kadar devam etti ve ardından büyük bir değişim ile karşılaştık.

Borland, programlama ürünlerini CodeGear isimli firmaya devretmiş ve ardından bu ürünleri Embarcadero isimli bir firma satın almıştı. Bu süreçte, artık Delphi ve diğer programlama ortamlarının .Net’e destek vermemesine karar verildi. Bu son derece yerinde bir karardı. Delphi, hayata ilk geldiği 1995 yılından bu zamana kadar native uygulama geliştirme konusunda, dünyada pek çok kez ödül almış bir ortam iken, .Net framework desteği adına adeta kendi kendine intihar etme kararı almıştı.

Günümüzde, .Net programlama adına Delphi yazım tarzına aşina olan programcıların Delphi Prism ürününü tercih etmesi isteniyor. Bu ürün; .Net framework ortamına %100 destek veren ve Delphi yazım tarzına son derece benzeyen Embarcadero firması programlama ortamları ailesinin bir başka ürünü.

Embarcadero, Delphi ürününü satın aldıktan sonra, beklentilerimizin aksine bu ürün ailesine son derece önem verdi ve ürünün eskide olduğu gibi popülerliğini yeniden kazanmasında büyük katkı sağlamaya başladı. Bu konuda sevgili arkadaşımız Sadettin POLAT’ın sitesindeki makaleyi okumanızı öneriyorum.

Konumuzun Win32 ve .Net olması münasebeti ile, kısa bir zaman sonra çıkması beklenen yeni Delphi sürümünün yani Delphi Weaver’ın çok önem verdiğim bir özelliğini de sizlerle paylaşmak istiyorum. Delphi Weaver’ın özelliklerinde listelenen ancak pek çok kişinin dikkatini cezbetmeyen, “Seamless .NET <> Native communication” özelliği eminim pek çok kişinin native uygulama geliştirebilecekleri ortamlara geçişinde etken olacaktır. Peki nedir bu “Seamless .NET <> Native communication” özelliği ?

Bu özellik hakkında henüz net bir şey söz konusu değil. Ancak, neler yapılabileceği hususunda ; burayı ve bu haber grubunu takip etmenizi tavsiye edebilirim.

Kısaca; Win32 ortamında tamamen native kod geliştirirken, .Net framework fonksiyonalitesine herhangi bir COM bağımlılığı olmadan, %100 delphi kodları ile erişmek isterseniz bu teknoloji tam size göre demektir.

Atozed Software’in üzerinde çalıştığı CrossTalk isimli ürün, Delphi 5,6,7..2009 altından .Net Framework’e erişebilmeniz için gereken tüm altyapıyı sağlayacak. Projenin lideri olan Chad Z. Hover ile yapmış olduğum görüşme neticesinde öğrendiğim şey ise beni daha da sevindirdi. CrosTalk ürünü Delphi Weawer ile birlikte gelecek. Yani birkaç paragraf önce belirttiğimiz “Seamless .NET <> Native communication” Delphi Weaver altındaki CrossTalk ürününü simgeliyor.

Bu yeni teknolojinin Delphi’nin yükselmesinde büyük bir paydaya hizmet edeceği inancını taşıyorum. Ayrıca Delphi’nin hedefleri arasında Cross platform code compilation olduğunu da bilmenizi istiyorum. İşte gerçek platform bağımsız kodlama bizlerin hizmetine sunulacak. Delphi’de yazdığımız uygulamaları Windows, Linux yada MacOS gibi işletim sistemleri üzerinde çalışır halde göreceğiz. Elbette bu, .Net’in yada Java’nın yaptığı gibi değil, native derleme ile yapılacak.

Tüm bu anlatılanlar, belki de hâla afaki kalmış olabilir. CrossTalk’ın yahut Delphi Weaver içindeki “Seamless .NET <> Native communication” özelliğinin ne kadar önemli olduğu anlaşılmamış da olabilir. Bunun önemini anlatabilmek için, Win32′den .Net’e erişmeye çalışmak gerekir.

Bu makalede, Win32 ortamından .Net Framework’e erişeceğiz ve tüm bu zorlukları sizlerin gözleri önüne sereceğim. Öncelikle Visual Studio 2005 ile bir Class Library(DLL) oluşturacağız.Bu DLL’imiz SQL Server 2005′e erişim sağlayan bir kaç sınıftan ibaret olacak. Ve Bu DLL’imizi Delphi 7 altından kullanacağız.

O halde kodlamaya başlayabiliriz. Öncelikle Visual Studio’muzu açıyoruz ve yeni bir Class Library projesi oluşturuyoruz. Ardından Microsoft.SqlServer.ConnectionInfo, Microsoft.SqlServer.Smo, Microsoft.SqlServer.SmoEnum, Microsoft.SqlServer.SqlEnum library’lerini referans olarak ekliyoruz. Projemiz aşağıda göründüğü gibi olacaktır:

Bu makalenin can alıcı noktası, .Net ortamında yazdığımız kodlarımızın dışarıdan(Win32 ortamından) kullanılabilmesi için COM programlamadan istifade edeceğimiz gerçeğidir. COM programlama kullanacağımıza göre, dışarıdan erişime açacağımız tüm sınıfların ComVisible attribute’u ile görünür hâle getirilmesi gerekir. Bir diğer önemli nokta ise, Class Library projemizin özelliklerinde gizlidir. Bu özel durumları aşağıdaki görsellerden izleyebilirsiniz:

Projemizin Application bölümünden Assembly Information buttonuna tıklanarak yapılalacak ayarlar:

Projemizin Build sayfasında yapılacak ayarlar:

Bu ayarların yapılmasına müteakip, C# tarafında SQL Server 2005′e bağlanan, ve bir veritabanının altındaki tüm tablolara erişim sağlayabileceğimiz kodları yazmaya başlamadan evvel anlatmamız gereken bir kaç husus daha var. Bunlardan en önemlisi; .Net framework platformundaki her veri türünü COM ortamında kullanmanın zorluklarıdır. Kullanmak istediğimiz veri türleri, ki bunların içinde özel sınıflar, framework sınıfları gibi tüm veri türleri ComVisible attribute’u ile işaretlenmiş olmalıdır. .Net ortamındaki tüm türlerin nasıl yönetileceğini dış uygulamalar bilemezler. Binlerce tür olduğu hesaplanırsa, bu türlerin hepsinin ComVisible ile işaretlenmesinin ne kadar zor olduğu da aşikârdır.

Makalemizin başlarında, temel veri türlerinin .Net içinde tanımlı olduğunu ifade etmiştik. Bu CTS adını almıştı ve pek çok programlama dilinin bir arada çalışabilmesi için son derece faydalı bir unsurdu. Ancak, şimdi bizim için bir sorun gibi duruyor. CTS içinde tanımlı olan bazı basit değişken türlerinin COM programlama da ComVisible ile görünür hâle getirilmeden de kullanılabildiğini ifade etmek sanırım sizleri biraz rahatlatacaktır ancak yine de yeteri derece de rahatlamamış olmanız gerekir. Çünkü, pek çok projemizde bu projemizde olduğu gibi, Integer, String vb. gibi basit veri türleri bizim için yeterli değildir.

.Net framework’ün Smo kütüphanesi ile Sql Server’a erişebildiğini biliyoruz. Ve bu Smo kütüphanesi içinde Sql Server içindeki hemen hemen her nesne için tanımlanmış bir veri tipi bulunmaktadır.(Genellikle bir sınıf). Peki biz bu veritiplerini dışarıya nasıl sunacağız ? Smo namespace’ininin tamamını mı ComVisible ile işaretleyeceğiz ?

Elbette hayır. Bu son derece uğraştırıcı ve zor bir durum olurdu. Bu sebeple, Smo kütüphanesi içinde ilgilendiğimiz sınıflara karar verecek ve bu sınıflar için bir arabirim yazacağız. Ardından bu arabirimi görünür kılacağız

Örneğin, biz bu uygulamamızda Sql Server 2005′e erişip herhangi bir veritabanının içindeki tüm tablo‘lara ulaşmak istediğimize göre, Smo namespace’indeki Table sınıfına ait sahte bir interface düzenleyeceğiz. Gelin biraz da kodlayalım ki daha anlaşılır olsun:

using System;
using System.Collections.Generic;
using System.Text;

using Microsoft.SqlServer.Management.Smo;
using Microsoft.SqlServer.Management.Common;
using System.Runtime.InteropServices;

namespace SQLClassLibrary
{
    [ComVisible(true)]
    public interface ITableInterface
    {
        DateTime CreateDate { get; }
        string Name { get; }
        long RowCount { get; }
        int ColumnCount { get; }
        int TriggerCount { get; }
    }

    public class TableClass : ITableInterface
    {
        private Table ActiveTable;

        public DateTime CreateDate
        {
            get
            {
                return ActiveTable.CreateDate;
            }
        }
        public string Name
        {
            get
            {
                return ActiveTable.Name;
            }
        }
        public long RowCount
        {
            get
            {
                return ActiveTable.RowCount;
            }
        }
        public int ColumnCount
        {
            get
            {
                return ActiveTable.Columns.Count;
            }
        }
        public int TriggerCount
        {
            get
            {
                return ActiveTable.Triggers.Count;
            }
        }

        public TableClass(Table tbl)
        {
            ActiveTable = tbl;
        }

        ~TableClass()
        {
            // Nesneleri yok etmeyi unutma.! GC ye güvenme..
        }
    }

    public class SQLServerClass
    {
    }
}

Yukarıdaki kod örneğimizde öncelikle System.Runtime.InteropServices isimli alanı using bloğuna eklediğimizi görüyorsunuz. ComVisible attribute’unu kullanmak için bunu yapmak durumundayız. Ardından Smo namespace’i içinde tanımlı olan Table isimli sınıfın ilgilendiğimiz birkaç tane property’sini tanımladığımız ITableInterface arabiriminin içinde görüyorsunuz. Bu arabirim, ComVisible ile işaretli durumda. Biz ileride Delphi üzerinden yazdığımız C# kodlarını kullanırken arabirim referanslarına erişeceğiz

Ardından basit bir sınıf olan TableClass sınıfının ITableInterface arabirimini implemente ettiğini görüyorsunuz. Sizinde farkettiğiniz gibi, bu sınıf ComVisible ile işaretlenmemiş. Çünkü biz bu sınıfa ilgili arabirimi üzerinden erişim sağlayacağız. Dolayısı ile sınıfımız ITableInterface’i implemente ettiği için sadece arabirimi ComVisible ile görünür kılmak bizim için yeterli olacaktır.

Buradaki anafikri anlamanız çok önemli. .Net framework altındaki kompleks yapıları COM ortamından kullanabilmek için onların COM görünürlüğünün sağlanması gereklidir. Biz bu uygulamamızda .Net framework’ün Smo kütüphanesi içindeki Table isimli sınıfı bu sebeple dışarıya veremedik ! İlgili sınıfı(Table) ComVisible ile görünür kılamadığımız için, biz de bu sınıfın sahte bir kopyasına bir arabirim oluşturduk ve o kopyayı görünür kıldık. Meselenin özü aslında sadece bu kadar. Şimdi Sql Server 2005′e erişim sağlamasını düşündüğümüz sınıfımıza birer adet Connect ve Disconnect metodu yazmamız işimizi görecek midir ? Evet server’a bağlanmak için server’ın adına ve bağlantı şifresine ihtiyaç duyacağız ancak peki ya hangi veritabanından ilgili tabloları alacağız ?

Bu noktada bizim için bir de Smo namespace’indeki Database sınıfına bir interface uydurmamız gerekecek. Bu interface’de aşağıdaki gibi olacak:

    [ComVisible(true)]
    public interface IDatabaseInterface
    {
        int ActiveConnections { get; }
        DateTime CreateDate { get; }
        DateTime LastBackupDate { get; }
        string Name { get; }
        double Size { get; }

        int StoredProcedureCount { get; }
        int TableCount { get; }
        int UserDefinedFunctionCount { get; }
        int ViewCount { get; }

        ITableInterface TableFromName(string TableName);
        ITableInterface TableFromIndex(int Index);
    }

    public class DatabaseClass : IDatabaseInterface
    {
        private Database ActiveDatabase;
        private Hashtable hTables;

        public int ActiveConnections
        {
            get
            {
                return ActiveDatabase.ActiveConnections;
            }
        }
        public string Collation
        {
            get
            {
                return ActiveDatabase.Collation;
            }
            set
            {
                ActiveDatabase.Collation = value;
                ActiveDatabase.Alter();
            }
        }
        public DateTime CreateDate
        {
            get
            {
                return ActiveDatabase.CreateDate;
            }
        }
        public DateTime LastBackupDate
        {
            get
            {
                return ActiveDatabase.LastBackupDate;
            }
        }
        public string Name
        {
            get
            {
                return ActiveDatabase.Name;
            }
        }
        public double Size
        {
            get
            {
                return ActiveDatabase.Size;
            }
        }
        public int StoredProcedureCount
        {
            get
            {
                return ActiveDatabase.StoredProcedures.Count;
            }
        }
        public int TableCount
        {
            get
            {
                return ActiveDatabase.Tables.Count;
            }
        }
        public int UserDefinedFunctionCount
        {
            get
            {
                return ActiveDatabase.UserDefinedFunctions.Count;
            }
        }
        public int ViewCount
        {
            get
            {
                return ActiveDatabase.Views.Count;
            }
        }

        public ITableInterface TableFromName(string TableName)
        {
            return (ITableInterface)hTables[TableName];
        }

        public ITableInterface TableFromIndex(int Index)
        {
            ITableInterface Result = null;

            int iCounter = 0;
            IDictionaryEnumerator TableEnum = hTables.GetEnumerator();
            while (TableEnum.MoveNext())
            {
                if (iCounter == Index)
                {
                    Result = (TableClass)TableEnum.Value;
                    break;
                }

                iCounter += 1;
            }

            return Result;
        }

        public DatabaseClass(Database db)
        {
            ActiveDatabase = db;
            hTables = new Hashtable();

            foreach (Table tbl in ActiveDatabase.Tables)
            {
                if (!tbl.IsSystemObject) hTables.Add(tbl.Name, new TableClass(tbl));
            }
        }
    }

Yukarıda IDatabaseInterface tanımını ve bu interface’i implemente eden sınıfın tanımını görüyorsunuz. Biz ilgili veritabanının tablolarına TableFromName ve TableFromIndex metodları ile erişeceğiz. Bu durumda artık son sınıfımız olan en başta tanımını boş olarak gördüğünüz SQLServerClass sınıfını yazmaya başlayabiliriz. Ancak bu sınıfımız içinde bir interface tasarlamamız ve ComVisible ile görünür kılmamız gerekiyor. Tanım aşağıdaki gibi olacak;

    [ComVisible(true)]
    public interface ISQLLibrary
    {
        bool Connect(string ServerName, string DatabaseName, string UserName, string Password);
        void Disconnect();

        IDatabaseInterface Database { get; }
    }

    public class SQLServerClass : ISQLLibrary
    {
        private Server srv;
        private IDatabaseInterface CurrentDatabase;

        public IDatabaseInterface Database
        {
            get
            {
                return CurrentDatabase;
            }
        }

        public bool Connect(
                            string ServerName,
                            string DatabaseName,
                            string UserName,
                            string Password
                           )
        {
            bool Result = false;

            srv = new Server(ServerName);
            srv.ConnectionContext.LoginSecure = false;
            srv.ConnectionContext.Login = UserName;
            srv.ConnectionContext.Password = Password;
            Result = true;

            if (Result)
            {
                Database db = srv.Databases[DatabaseName];
                CurrentDatabase = new DatabaseClass(db);
            }

            return Result;
        }

        public void Disconnect()
        {
            srv.ConnectionContext.Disconnect();
        }

        ~SQLServerClass()
        {
            Disconnect();
        }
    }

Görüldüğü gibi son derece basit bir yapıya sahip olan SQLServerClass sınıfımız ISQLLibrary interface’ini implemente etmiş ve ISQLLibrary ComVisible ile görünür hâle getirilmiş. Kodumuzun nihai hali aşağıdaki gibi olacaktır:

using System;
using System.Collections.Generic;
using System.Text;

using Microsoft.SqlServer.Management.Smo;
using Microsoft.SqlServer.Management.Common;
using System.Runtime.InteropServices;
using System.Collections;

namespace SQLClassLibrary
{
    [ComVisible(true)]
    public interface ITableInterface
    {
        DateTime CreateDate { get; }
        string Name { get; }
        long RowCount { get; }
        int ColumnCount { get; }
        int TriggerCount { get; }
    }

    public class TableClass : ITableInterface
    {
        private Table ActiveTable;

        public DateTime CreateDate
        {
            get
            {
                return ActiveTable.CreateDate;
            }
        }
        public string Name
        {
            get
            {
                return ActiveTable.Name;
            }
        }
        public long RowCount
        {
            get
            {
                return ActiveTable.RowCount;
            }
        }
        public int ColumnCount
        {
            get
            {
                return ActiveTable.Columns.Count;
            }
        }
        public int TriggerCount
        {
            get
            {
                return ActiveTable.Triggers.Count;
            }
        }

        public TableClass(Table tbl)
        {
            ActiveTable = tbl;
        }

        ~TableClass()
        {
            // Nesneleri yok etmeyi unutma.! GC ye güvenme..
        }
    }

    [ComVisible(true)]
    public interface IDatabaseInterface
    {
        int ActiveConnections { get; }
        DateTime CreateDate { get; }
        DateTime LastBackupDate { get; }
        string Name { get; }
        double Size { get; }

        int StoredProcedureCount { get; }
        int TableCount { get; }
        int UserDefinedFunctionCount { get; }
        int ViewCount { get; }

        ITableInterface TableFromName(string TableName);
        ITableInterface TableFromIndex(int Index);
    }

    public class DatabaseClass : IDatabaseInterface
    {
        private Database ActiveDatabase;
        private Hashtable hTables;

        public int ActiveConnections
        {
            get
            {
                return ActiveDatabase.ActiveConnections;
            }
        }
        public string Collation
        {
            get
            {
                return ActiveDatabase.Collation;
            }
            set
            {
                ActiveDatabase.Collation = value;
                ActiveDatabase.Alter();
            }
        }
        public DateTime CreateDate
        {
            get
            {
                return ActiveDatabase.CreateDate;
            }
        }
        public DateTime LastBackupDate
        {
            get
            {
                return ActiveDatabase.LastBackupDate;
            }
        }
        public string Name
        {
            get
            {
                return ActiveDatabase.Name;
            }
        }
        public double Size
        {
            get
            {
                return ActiveDatabase.Size;
            }
        }
        public int StoredProcedureCount
        {
            get
            {
                return ActiveDatabase.StoredProcedures.Count;
            }
        }
        public int TableCount
        {
            get
            {
                return ActiveDatabase.Tables.Count;
            }
        }
        public int UserDefinedFunctionCount
        {
            get
            {
                return ActiveDatabase.UserDefinedFunctions.Count;
            }
        }
        public int ViewCount
        {
            get
            {
                return ActiveDatabase.Views.Count;
            }
        }

        public ITableInterface TableFromName(string TableName)
        {
            return (ITableInterface)hTables[TableName];
        }

        public ITableInterface TableFromIndex(int Index)
        {
            ITableInterface Result = null;

            int iCounter = 0;
            IDictionaryEnumerator TableEnum = hTables.GetEnumerator();
            while (TableEnum.MoveNext())
            {
                if (iCounter == Index)
                {
                    Result = (TableClass)TableEnum.Value;
                    break;
                }

                iCounter += 1;
            }

            return Result;
        }

        public DatabaseClass(Database db)
        {
            ActiveDatabase = db;
            hTables = new Hashtable();

            foreach (Table tbl in ActiveDatabase.Tables)
            {
                if (!tbl.IsSystemObject) hTables.Add(tbl.Name, new TableClass(tbl));
            }
        }
    }

    [ComVisible(true)]
    public interface ISQLLibrary
    {
        bool Connect(string ServerName, string DatabaseName, string UserName, string Password);
        void Disconnect();

        IDatabaseInterface Database { get; }
    }

    public class SQLServerClass : ISQLLibrary
    {
        private Server srv;
        private IDatabaseInterface CurrentDatabase;

        public IDatabaseInterface Database
        {
            get
            {
                return CurrentDatabase;
            }
        }

        public bool Connect(
                            string ServerName,
                            string DatabaseName,
                            string UserName,
                            string Password
                           )
        {
            bool Result = false;

            srv = new Server(ServerName);
            srv.ConnectionContext.LoginSecure = false;
            srv.ConnectionContext.Login = UserName;
            srv.ConnectionContext.Password = Password;
            Result = true;

            if (Result)
            {
                Database db = srv.Databases[DatabaseName];
                CurrentDatabase = new DatabaseClass(db);
            }

            return Result;
        }

        public void Disconnect()
        {
            srv.ConnectionContext.Disconnect();
        }

        ~SQLServerClass()
        {
            Disconnect();
        }

    }
}

Şimdi Visual Studio ortamında Ctrl+Shift+B tuşlarına basarak yada Build menüsünden Build seçeneklerinden birisini seçerek derleme işlemi yaptığımızda Delphi tarafına geçmeye hazırız demektir. İlgili DLL’imiz artık projemizi kaydettiğimiz yerde oluşturulduğu gibi, proje ayarlarından Com görünürlüğünü işaretlediğimiz için bu DLL aynı zamanda COM sistemine Register edilmiş durumdadır. Eğer elle register işlemi yapmak istiyorsanız o halde, regasm kullanmak durumunda kalacaksınız. Ancak şu anda bu işi Visual Studio bizim için yapmış durumda. Delphi’mize geçip yeni bir proje açalım, ve Project/Import Type Library adımından aşağıdaki görselde görebileceğiniz gibi ilgili DLL’imizi listeden bulalım ve Create Unit’e basalım.

SQLClassLibrary_TLB.pas isimli dosyamız artık oluşmuş durumda. Delphi örneğimiz ise aşağıdaki gibi olacaktır;

uses SQLClassLibrary_TLB;
..
..
..
procedure TForm1.Button1Click(Sender: TObject);
var
  SqlServer : ISQLLibrary;
begin
  SqlServer := CoSQLServerClass.Create as ISqlLibrary;
  SqlServer.Connect('TUGRUL', 'BENIMDB', 'sa', '*****');
  ShowMessage(
     Format('Kayıt Sayısı=%d, Kolon Sayısı=%d',
       [
         SqlServer.Database.TableFromName('BenimTablom').RowCount,
         SqlServer.Database.TableFromName('BenimTablom').ColumnCount
       ]) );
  SqlServer.Disconnect;
  SqlServer := nil;
end;

Özetlemek gerekir ise, Delphi Win32 projelerinde herhangi bir .Net framework kütüphanesine erişebilir ve onu kullanabilirsiniz. Ancak ComVisible görünürlük durumuna dikkat ederek Sanırım şimdi makalemin başlarında belirttiğim, CrossTalk ve Delphi Weaver içinde .Net erişimi özelliklerinin ne derece önemli olduğu daha açıktır.

Saygılar, sevgiler..