Yazdığınız bir uygulamanın vakit alıcı bazı işlerini, Windows’un kullanılmadığı zamanlarda gerçekleştirmek isteyebilirsiniz.

Yapmamız gereken, uygulamamızın, Windows’un kullanılmadığı zamanı anlayabileceği ve sayabileceği bir yönteme sahip olmasını sağlamak.

Böylece Windows belirli bir süre boyunca kullanılmadığında, uygulamamızın çeşitli görevleri başlatmasını sağlayabiliriz.

Windows’un kullanılmadığı süreyi ölçmek için, öncelikle son kullanıldığı zamanı bulmamız gerekmektedir.

İlk olarak, kodumuzun using kısmına System , System.Runtime.InteropServices ve System.Timers namespace‘lerini ekleyelim.

System.Runtime.InteropServices namespace’i Windows API‘lerini uygulamamıza eklememize yarayan sınıfları barındırmaktadır.

GetLastInputInfo methodunu uygulamamıza ekleyebiliriz.

GetLastInputInfo method’u sayesinde ihtiyacımız olan, Windows’un son kullanılma zamanını alabileceğiz.

[DllImport(“user32.dll”)] static extern bool GetLastInputInfo(ref LastInputInfo plii);</pre>

Toplam Kullanılma Zamanından, Son Kullanılma Zamanını çıkarttığımızda, Windows’un Kullanılmadığı Boş Zamanı bulmuş olacağız.

TimeSpan.FromMilliseconds(Environment.TickCount - info.dwTime)

GetLastInputInfo method’u parametre olarak LastInputInfo tipinde bir struct istemektedir.

public struct LastInputInfo
{
    public uint cbSize;
    public uint dwTime;
}

Uygulamamızın başlangıcında bir Timer oluşturuyoruz ve Elapsed olayında, Windows’un kullanılmadığı süreyi ekrana yazdırıyoruz.

Örnek uygulamanın tüm kodu;

using System;
using System.Runtime.InteropServices;
using System.Timers;

public struct LastInputInfo
{
    public uint cbSize;
    public uint dwTime;
}

public class Program
{
    [DllImport("user32.dll")]
    static extern bool GetLastInputInfo(ref LastInputInfo plii);

    static LastInputInfo info = new LastInputInfo();

    public static TimeSpan GetInactiveTime()
    {
        if (GetLastInputInfo(ref info))
            return TimeSpan.FromMilliseconds(Environment.TickCount - info.dwTime);
        else
            return TimeSpan.Zero;
    }

    static void Main(string[] args)
    {
        info.cbSize = (uint)Marshal.SizeOf(info);

        Timer t = new Timer(1000);
        t.Start();
        t.Elapsed += delegate { Console.WriteLine(GetInactiveTime().ToString()); };

        Console.ReadLine();
    }
}

Thread sınıfı ile ilgili en çok karşılaştığım sorulardan birisi; “Thread.Sleep() ile Thread.SpinWait() method’ları arasındaki fark nedir?” olmuştur.

MSDN Process ve Thread dökümanları ne yazık ki bu konuda bize yeterli bilgi sağlamıyor.

Peki Thread sınıfının SpinWait() ve Sleep() method’ları arasındaki fark nedir?

Programming .Net Components kitabının yazarı Juval Löwy‘den alıntı (sayfa 192) yapacağım;

Orjinal : When a thread calls SpinWait(), the calling thread waits the number of iterations specified, and the thread is never added to the queue of waiting threads. As a result, the thread is effectively put to sleep without relinquishing the remainder of its CPU time slot.

The .NET documentation does not define what an iteration is, but it is likely mapped to a predetermined number (probably just one) of NOP (no-operations) assembly instructions. Consequently, the following SpinWait() instruction will take different time to complete on machines with different CPU clock speeds:

const long MILLION = 1000000; Thread.SpinWait(MILLION);

SpinWait() is not intended to replace Sleep(), but is rather made available as an advanced optimization technique. If you know that some resource your thread is waiting for will become available in the immediate future, it is potentially more efficient to spin and wait, instead of using either Sleep() or a synchronization object, because those force a thread context switch, which is one of the most expensive operations performed by the operating system. Even in the esoteric cases for which SpinWait() was designed, using it is an educated guess at best. SpinWait() will gain you nothing if the resource is not available at the end of the call, or if the operating system preempts your thread because its time slot has elapsed, or because another thread with a higher priority is ready to run. In general, I recommend that you should always use deterministic programming (using synchronization objects in this case) and avoid optimization techniques.

Alıntı’nın önemli cümleleri;

Türkçesi : Eğer bir thread SpinWait() method’unu çağırırsa, parametre ile belirtilen CPU çevrimi boyunca beklemeye geçer ve Bekleyen Threadler (Waiting Threads) listesine kendini eklemez. Böylece, CPU’da bulunduğu slot’tan vazgeçmeden, uyku moduna geçmiş olur.

.NET dokümantasyonuna göre her CPU çevriminde (muhtemelen) bir adet NOP (no-operations) assembly komutu çalıştırır. Fakat, aşağıdaki SpinWait() komutu, farklı hızlarda çalışan CPU’larda farklı sürelerde tamamlanır.

const long MILLION = 1000000; Thread.SpinWait(MILLION);

SpinWait() method’u, Sleep() method’unun yerine düşünülmemiştir, daha ileri seviye optimizasyon yapılabilmesi için amaçlanmıştır. Eğer çalışan thread’in ihtiyaç duyduğu kaynak, çok kısa süre içerisinde uygun olacaksa (mesela başka bir thread kaynak üzerinde bulunan lock’ı kaldıracaksa) Sleep() yerine SpinWait() kullanmak daha uygun olur.

Sleep() method’u (veya syncronization nesnesi), thread’in CPU üzerinde context switch yapmasına sebep olur.

Son cümle; SpinWait() method’u, çağıran thread’i, işlemci üzerinde aktif tutar, Sleep() method’u ise, thread’i belirli süre boyunca gerçek anlamda uyutur.

BilgeAdam’daki eski öğrencilerimden biri şu soruyu sordu; “Herhangi bir veritabanındaki tüm tablolarda bulunan Identity Sütunları belirlemenin bir yolu var mıdır?”

Aslında bir değil, tam üç yolu var;

Yöntem 1 : COLUMNPROPERTY fonksiyonunu kullanmak

SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMNPROPERTY(OBJECT_ID(TABLE_NAME), COLUMN_NAME, ‘ISIDENTITY’) = 1 ORDER BY TABLE_NAME</pre>

Yöntem 2 : SYS.ALL_COLUMNS View’unu kullanmak

SELECT
    OBJECT_NAME(AC.OBJECT_ID),
    SO.NAME
FROM
    SYS.ALL_COLUMNS AS AC
    INNER JOIN SYS.OBJECTS AS SO ON OBJECT_NAME(AC.OBJECT_ID) = SO.NAME
WHERE
    AC.IS_IDENTITY = 1 AND
    SO.TYPE = 'U'

Aynı yöntemi biraz faklı olarak şöyle de yazabiliriz;

SELECT
    OBJECT_NAME(OBJECT_ID),
    NAME
FROM
    SYS.ALL_COLUMNS
WHERE
    IS_IDENTITY = 1 AND
    OBJECTPROPERTY(OBJECT_ID, 'ISUSERTABLE') = 1

Yöntem 3 : SYS.IDENTITY_COLUMNS View’unu kullanmak

SELECT
    OBJECT_NAME(IC.OBJECT_ID),
    SO.NAME
FROM
    sys.identity_columns AS IC
    INNER JOIN SYS.OBJECTS AS SO ON OBJECT_NAME(IC.OBJECT_ID) = SO.NAME
WHERE
    SO.TYPE = 'U'

Aynı yöntemi biraz faklı olarak şöyle de yazabiliriz;

SELECT
    OBJECT_NAME(OBJECT_ID),
    NAME
FROM
    sys.identity_columns
WHERE
    OBJECTPROPERTY(OBJECT_ID, 'ISUSERTABLE') = 1

C# 4.0 ile hayatımıza giren dynamic ve C# 1.0‘dan beri varolan object arasında ne fark var?

Önce eski dostumuz object ile başlayalım;

object anahtar kelimesi aslında System.Object sınıfının bir kısaltmasından başka birşey değildir (ki kendisi C# sınıf hiyerarşisinin en temelinde yer almaktadır)

Not : Birçoğumuzun bildiği gibi, aslında herşey object sınıfından türememektedir. bknz: Eric Lippert’in MSDN Blog yazısı

object tipinde bir değişkene, hemen hemen istediğimiz her değeri atayabiliriz. Birkaç örnek;

object Rakam = 10; Console.WriteLine(Rakam.GetType()); /// System.Int32

Rakam = Rakam + 10; /// Derleme zamanı hatası. Çünkü derleme anında Rakam değişkeni System.Object tipinde

Rakam = (int)Rakam + 10; /// Hatasız atama için, unboxing yapmamız gerekiyor</pre>

Örnekte gördüğümüz gibi, Rakam değişkeninde rakamsal bir değer tutuyor olmamıza rağmen, derleyici, değişken üzerinde matematiksel işlem yapmamıza izin vermedi.

Değişken’in değerine erişebilmek için unboxing yapmak zorunda kaldık ve tip güvenliği olmadığı için çalışma zamanı hataları oluşturabilecek, zayıf bir kod ortaya çıktı.

Bir de C# 4.0 ile birlikte gelen dynamic inceleyelim;

dynamic Rakam = 10;
Console.WriteLine(Rakam.GetType());
/// object için aldığımız sonucun aynısını alıyoruz
/// System.Int32

Rakam = Rakam + 10;
/// Derleme zamanı hatası almayız, çünkü derleyici tipi çözümlemek için uğraşmaz.

Bu, object ile dynamic arasındaki en temel farktır. dynamic ile, derleyici‘ye (compiler), nesnenin tipinin sadece çalışma zamanında bilinebileceğini söylemiş oluyoruz.

*Sonuçta aslında derleme zamanı için daha az kod yazıyoruz.

Fakat bu dynamic anahtar kelimesini daha az tehlikeli veya daha tehlikeli duruma getirmez.*

Genelde bir sonraki soru; “dynamic ile herhangi bir method’a uygun olmayan tipte parametre gönderip, hata oluşmasını sağlayabilir miyim?” oluyor.

Basit bir örnek ile bu soruyu test edelim;

public static void AdSoyadYaz(string Ad, string Soyad)
{
    Console.WriteLine(Ad + " " + Soyad);
}

Bu method’umuzu dynamic tipindeki bir değişken ile çağıralım;

dynamic Ad = 10;
dynamic Soyad = 20;

/// Çalışma zamanı hatası almanız lazım.
AdSoyadYaz(Ad, Soyad);

Yukarıdaki kod ile, çalışma zamanında RuntimeBinderException tipinde bir hata almalısınız. Hatanın Message property’sinde; “The best overloaded method match for ‘AdSoyadYaz(string, string)’ has some invalid arguments” yazıyor olmalı.

dynamic Ad = "Engin";
dynamic Soyad = "Polat";

AdSoyadYaz(Ad, Soyad);

Gördüğünüz gibi, method’un çalıştırılması için parametre tipleri çalışma zamanında kontrol edilir, ve uygunsuz ise, RuntimeBinderException tipinde bir hata fırlatılır.

object anahtar kelimesinde ise, bu süreç derleme zamanında kontrol edilir.

object Ad = 10;
object Soyad = 20;

/// Derleme zamanı hatası almanız lazım.
AdSoyadYaz(Ad, Soyad);

object Ad = "Engin";
object Soyad = "Polat";

AdSoyadYaz((string)Ad, (string)Soyad);

Aşağıdaki kod parçasına, programlama üzerine yazılmış bir makaleyi okurken rastladım;

public void IsNullOrEmpty<T>(IEnumerable<T> koleksiyon) { if (koleksiyon == null || koleksiyon.Count() == 0) { /// Koleksiyon’da hiç eleman yok /// Koleksiyon boş } }</pre>

Yukarıdaki method IEnumerable generic tipinde parametre alıyor, null veya boş olup/olmadığını kontrol ediyor.

Karşılaştırmada kullanılan,

Liste.Count() == 0

kod parçası dikkatimi çekti.

Eğer IsNullOrEmpty fonksiyonuna parametre olarak ICollection<T> interface‘ini implemente etmeyen tipten bir değer gönderecek olursak (mesela LINQ sorgusu sonucu olarak IQueryable) Count method’u tüm liste üzerinde satır-satır ilerleyerek listedeki eleman adedini hesaplayacaktır.

Eğer fonksiyona parametre olarak IEnumerable interface‘ini implemente eden tipten bir değer gönderecek olursak, Count method’u, optimize edilmiş haliyle, sadece koleksiyonun Count özelliğini sorgulayacaktır.

Türkçe ifadesiyle; “Koleksiyonda eleman var mı?” sorusu yerine “Koleksiyon’da sıfır eleman mı var?” sorusunu sormuş oluyoruz.

Aslında çözüm basit, System.Linq namespace‘inde yeralan Any extension method‘unu kullanmamız gerekiyor;

public void Test<T>(IEnumerable<T> koleksiyon)
{
    if (koleksiyon == null || !koleksiyon.Any())
    {
        /// Koleksiyon'da hiç eleman yok
        /// Koleksiyon boş
    }
}

Bu yöntemin güzelliği, IEnumerable interface‘inin MoveNext methodunu sadece bir kere çağırması. Koleksiyonda bulunan eleman adedi ne olursa olsun, Any methodu sonucu çok hızlı birşekilde döndürecektir.

Hatta kendi extension method‘umuzu da Any methodunu kullanarak yazabiliriz;

public static bool IsNullOrEmpty<T>(this IEnumerable<T> koleksiyon)
{
    return koleksiyon == null || !koleksiyon.Any();
}

Artık extension method‘u da yazdığımıza göre, asıl method‘u iyileştirebiliriz;

public void Test<T>(IEnumerable<T> koleksiyon)
{
    if (koleksiyon.IsNullOrEmpty())
    {
        /// Koleksiyon'da hiç eleman yok
        /// Koleksiyon boş
    }
}