C# ထဲက #derivative တွေအကြောင်း

#derivative ကို preprocessor derivative လို့လည်း ခေါ်ကြပါတယ်။ Compiler က ပရိုဂရမ်တစ်ခုကို Compile မလုပ်ခင်မှာ # နဲ့စတဲ့ derivative တွေကို အရင်ရှာပါတယ်။ အဲဒီ # တွေဟာ တချို့နေရာတွေမှာ အသုံးဝင်တာကို တွေ့ရပါတယ်။ အောက်မှာ ဖော်ပြထားတာကတော့ ကျွန်တော်လေ့လာမိသလောက်ပါ။

#warning

ကျွန်တော် မကြာခဏသုံးလေ့ရှိတဲ့ # တစ်ခုပါ။ အထူးသဖြင့် ကျွန်တော် ပရိုဂရမ်ထဲမှာ Test Data တွေကို ထည့်သုံးချင်ရင် ရေးလေ့ရှိပါတယ်။

#warning "Remove the following line after you had finished the testing"
MyData = 123;

အဲဒီလိုရေးထားတဲ့ အတွက် Compile လုပ်တဲ့အခါမှာ warning "Remove the following line after you had finished the testing" ဆိုတဲ့ စာကြောင်းက warning အနေနဲ့ ပေါ်ပါတယ်။ Test Data ကို ပရိုဂရမ်ထဲမှာ မေ့ပြီး ချန်မထားမိအောင် ကိုယ့်ဘာသာကိုယ် သတိပေးတဲ့သဘောမျိုးပါ။

#define #if #elif #else #endif

#define ဆိုတဲ့ Keyword ကို C Programming သင်ဖူးတဲ့သူတိုင်း သိကြမှာပါ။
#define PI 3.14159 ဆိုတာမျိုးတွေ ကျွန်တော်တို့ Constant ကြေငြာဖို့ သုံးခဲ့ဖူးပါတယ်။
C# မှာတော့ Constant ကြေငြာဖို့အတွက် const နဲ့ readonly စတဲ့ Keyword တွေကို သုံးပြီး ကြေငြာနိုင်ပါတယ်။

ဒါပေမယ့် တစ်ချို့နေရာတွေမှာတော့ #define ကို သုံးဖို့လိုအပ်ပြီး #if #elif #endif စတာတွေနဲ့ တွဲသုံးလို့ရပါတယ်။

ဥပမာအနေနဲ့ ပြောရရင် ကျွန်တော့်မှာ Class 3 ခုရှိတယ်ဆိုပါစို့။ နောက်ကျွန်တော့် ပရိုဂရမ်ကို Compile လုပ်တဲ့အခါမှာ Configuration1 အတွက် ClassA ကိုသုံးပြီး Compile လုပ်ချင်ပါတယ်။
Configuration2 အတွက်တော့ ClassB ကိုသုံးပြီး Compile လုပ်ချင်ပါတယ်။
ပုံမှန် Configuration အတွက်တော့ ClassC ကို သုံးပြီး Compile လုပ်ချင်ပါတယ်။
အဲဒီလို အချိန်မျိုးမှာ #define ကို #if #elif #else #endif နဲ့ တွဲပြီး အခုလိုသုံးလို့ရပါတယ်။

#define Configuration1

#if Configuration1
ClassA MyClass = new ClassA();
#elif Configuration 2
ClassB MyClass = new ClassB();
#else
ClassC MyClass = new ClassC()
#endif

အဲဒီလိုရေးရင် ClassA နဲ့ Compile လုပ်ပါလိမ့်မယ်။ Configuration1 အစား Configuration2 ကို define လုပ်ထားရင်တော့ ClassB နဲ့ Compile လုပ်ပါလိမ့်မယ်။ ဘာကို မှ define လုပ်မထားရင်တော့ ClassC နဲ့ Compile လုပ်ပါလိမ့်မယ်။

#define မကြေငြာပဲ Configuration1 ကို Project Properties ထဲမှာ Command Line Argument အနေနဲ့ ထည့်လို့လည်းရပါတယ်။

နောက်တစ်ခုသုံးနိုင်တာက ပရိုဂရမ်ကို Debug လုပ်တဲ့အချိန်မှာ တစ်ချို့ Function တွေကို Skip လုပ်ချင်တယ်ဆိုရင် အခုလိုရေးပေးလို့ ရပါတယ်။

void thisFunctionSkipAtDebug()
{
#if DEBUG
return;
#else
//your function code here
#endif
}

ပရိုဂရမ်က DEBUG လုပ်နေတဲ့ အချိန်မှာ DEBUG ကို define လုပ်ပြီးသား ဖြစ်တဲ့အတွက် သတ်သတ်ကြေငြာပေးစရာ မလိုပါဘူး။

#error

ပထမဥပမာနဲ့ပတ်သက်ပြီး မေးစရာတစ်ခုရှိလာပါတယ်။ အကယ်၍ ပရိုဂရမ်မှာ တစ်ယောက်ယောက်က Configuration1 ရော Configuration2 ပါ define လုပ်သွားရင် ဘယ်နှယ့်လုပ်မလဲ ဆိုတဲ့ မေးခွန်းပါ။ အဲဒီ Condition ကကျွန်တော်တို့အတွက် မလိုလားအပ်တဲ့ Condition မျိုးပါ။ အဲဒီလိုအခြေအနေ မှာ ပရိုဂရမ်ထဲမှာ အခုလို #error နဲ့ ရေးပြီး error message နဲ့ ပရိုဂရမ်ကို Compilation Fail ဖြစ်အောင် တားထားလို့ရပါတယ်။

#if Configuration1 && Configuration2
#error "Both Configuration1 and Configuration2 defined in the program."
#endif

#region #endregion

ဒီအသုံးအနှုန်းတွေကိုတော့ ကုတ်ဒ်ကို ဖတ်ရလွယ်အောင်လို့ တစ်ခါတစ်လေ သုံးတတ်ပါတယ်။
ဥပမာ ကျွန်တော့် ပရိုဂရမ်ထဲမှာ UI Enhancement လုပ်ထားတဲ့ Cosmetic Code တစ်ချို့ပါတယ် ဆိုပါစို့။ ကျွန်တော် အဲဒီကုတ်ဒ်တွေကို DEBUG လုပ်နေတုန်းမှာ မျက်စိရှုပ်ခံပြီး မကြည့်ချင်ရင် #region #endregion နဲ့ အခုလိုရေးထားပြီး Collapse လုပ်ပြီး ပိတ်ထားလို့ရပါတယ်။

#region My Cosmetic Code
//100 lines of cosmetic code here
#endregion

#region #endregion ဟာ Compile လုပ်တဲ့အချိန်မှာ ဘာမှ မပြောင်းလဲပါဘူး။ ကုတ်ဒ်ကို ဖတ်ရလွယ်အောင်လို့ သက်သက်သုံးတာပါ။

ဒီပို့စ်လည်း MyanmarITPro မှာ တင်ခဲ့ဖူးပါတယ်။

C# Windows Application ရဲ့ Program.cs နဲ့ပတ်သက်လို့

C# Windows Application တွေတိုင်းမှာ Program.cs ဆိုတဲ့ ဖိုင်တစ်ဖိုင် ပါပါတယ်။ များသောအားဖြင့် ကျွန်တော်တို့ အဲဒီဖိုင်ကို ပြင်လေ့မရှိကြပါဘူး။ ဒါပေမယ့် တစ်ခါတစ်လေမှာ Advance Features တွေအတွက် အဲဒီဖိုင်ကို ပြင်ဖို့လိုပါတယ်။ အဲဒီ ဖိုင်နဲ့ ပတ်သက်ပြီး ကျွန်တော် သိထားသမျှ အချက်အလက် အချို့ကို ဝေမျှ ချင်ပါတယ်။

Startup Form ကို ပြောင်းခြင်း

Program.cs ထဲမှာ ပရိုဂရမ်စတဲ့ အချိန်မှာ Form တစ်ခု ကို စပြီး Run ဖို့ အတွက် အခုလို ရေးထားပါတယ်။

Application.Run(new Form1());
 
အဲဒီစာကြောင်းကို ပြောင်းရေးရင် Startup Form ဟာ ပြောင်းသွားပါတယ်။

Application.Run(new Form2()); 

အဲဒီလို ပြောင်းလိုက်ရင် Form1 အစား Form2 ဟာ Startup Form ဖြစ်သွားပါတယ်။

Global Exception Catch လုပ်ခြင်း

Program ရေးတဲ့အခါမှာ ရုပ်အဆိုးဆုံးက Exception တွေ ဖမ်းလို့မရပဲ လွတ်ထွက်သွားတာမျိုးပါ။ ကျွန်တော်တို့ ဘယ်လောက်ပဲ သတိထားရေးရေး တစ်ခါတစ်ရံမှာ လွတ်ထွက်သွားတတ်ပါတယ်။ အဲဒီအခါမှာ ဆော့ဖ်ဝဲသုံးသူကို မက်ဆေ့ဖ် ပေးပြီး LogFile ထဲမှာ ရေးထားဖို့ လိုပါတယ်။ C# မှာ Global Exception Catch လုပ်ဖို့အတွက် Program.cs ကို ပြင်လို့ရပါတယ်။ အဲဒီလိုလုပ်ခြင်းအားဖြင့် ဘယ်နေရာက လွတ်ထွက်သွားတယ်ဆိုတာကို Stack Trace နဲ့အတူ LogFile ထဲမှာ ရေးထားနိုင်ပါတယ်။

Application.Run(new Form1()); ဆိုတဲ့ Statement မတိုင်ခင်မှာ ဒီလိုရေးပေးနိုင်ပါတယ်။

AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Application.Run(new Form1());

ပြီးရင် Main() Function ရဲ့ အပြင်ဖက်မှာ ဒီလိုပြန်ဖမ်းလို့ရပါတယ်။

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
//Write your catch code here
}

ရေးရမှာ ပျင်းရင် AppDomain.CurrentDomain.UnhandledException += ဆိုတဲ့ စာကြောင်းရိုက်ပြီးရင် Tab ၂ချက်ခေါက်လိုက်တာနဲ့ Event ရော၊ Function ပါထွက်လာပါလိမ့်မယ်။


Global Variable ကြေငြာခြင်း

C# ရဲ့ Built-in feature မှာ Global Variable မပါပါဘူး။ ဒါပေမယ့် Hardware နဲ့ ထိတွေ့နေရတဲ့ ပရိုဂရမ်တွေ အတွက်တော့ Global Variable ဟာ မရှိမဖြစ်လိုအပ်နေပါသေးတယ်။ အဲဒီတော့ ပရိုဂရမ်တစ်ခုလုံးက သုံးလို့ရတဲ့ Global Variable ကိုလိုချင်ရင် Program.cs ထဲမှာ ကြေငြာပေးလို့ရပါတယ်။

static class Program ဆိုတဲ့ Declaration အပြီးမှာ အခုလိုကြေငြာလို့ရပါတယ်။

public static int MyGlobalInt = 0;
အဲဒီ Variable ကို ပရိုဂရမ်ရဲ့ ဘယ်နေရာကဖြစ်ဖြစ် Program.MyGlobalInt ဆိုပြီး ပြန်ညွှန်းလို့ရပါတယ်။

Program Instance ၂ ခု Run လို့မရအောင် တားဆီးခြင်း

တစ်ခါတစ်လေမှာ ကျွန်တော်တို့ အနေနဲ့ Program Instance၂ ခု Run မှာကို မလိုလားပါဘူး။ အထူးသဖြင့် အရေးကြီးတဲ့ System Resource တွေကို ဝေမျှသုံးစွဲဖို့ မဖြစ်နိုင်တဲ့ အခါမျိုးမှာပါ။ အဲဒီအခါမှာ Main() Function ရဲ့ အစမှာ ဒီလိုရေးပြီး တားဆီးလို့ ရပါတယ်။

bool wasCreated;
System.Threading.Mutex aMutex = new System.Threading.Mutex(true, "My Software", out wasCreated);
if (!wasCreated)
{
MessageBox.Show("The program is already running.");
return;
}

အဲဒီလိုရေးထားတဲ့အတွက် Computer ပေါ်မှာ Program Instanceတစ်ခု Run ပြီးသားဖြစ်နေရင် နောက်တစ်ခု ထပ် Run တဲ့အခါမှာ Error Message ပေးပြီး ထွက်သွားပါလိမ့်မယ်။

Program မှ Parameters လက်ခံခြင်း

Program မှာ Command Line Parameters လက်ခံတဲ့အခါမှာ လိုအပ်သလိုပိုပြီး ထိန်းချုပ်လို့ရပါတယ်။ ဥပမာ ကိုယ့်ရဲ့ ပရိုဂရမ်ကို Mode အမျိုးမျိုးနဲ့ Run ချင်တဲ့အခါမှာ Parameters ဟာ အသုံးဝင်ပါတယ်။ အဲဒါတွင်မက ၀င်းဒိုးထဲမှာ ကိုယ့် ပရိုဂရမ်နဲ့ ဆိုင်တဲ့ File အိုင်ကွန်ကို ကလစ်နှိပ်လိုက်တဲ့အခါ ပရိုဂရမ်ကို အလိုအလျောက်စပြီး ကလစ်နှိပ်လိုက်တဲ့ ဖိုင်ကို ပရိုဂရမ်ထဲမှာ သုံးချင်တဲ့အခါမှာ (ဥပမာ Microsoft Word Documentကို ကလစ်နှိပ်ပြီး Run with Microsoft Word ဆိုရင် MS Word ထဲမှာ အလိုအလျောက်ပွင့်လာသလိုမျိုး)လည်း Parameters ကိုသုံးနိုင်ပါတယ်။ Parameters လက်ခံမယ်ဆိုရင်တော့ Main() Function ရဲ့ ခေါင်းစဉ်ကို အခုလိုပြင်ပေးရပါမယ်။

static void Main(string[] args)

အဲဒီနောက် Main() Function ထဲမှာ args ကို လိုသလိုသုံးနိုင်ပါတယ်။ args.Length ဆိုရင် Parameters ဘယ်နှစ်ခု ၀င်လာသလဲဆိုတာ ပြမှာဖြစ်ပြီး args[0] ဆိုရင် တော့ ပထမဆုံး Parameter ကို String အနေနဲ့ ရမှာဖြစ်ပါတယ်။

MyanmarITPro မှာ တင်ခဲ့ဖူးတဲ့ ဘလော့ခ်ပို့စ်တစ်ခုကို နည်းနည်း ပြန်ပြင်ပြီး တင်ထားတာပါ။

Multithreading သုံးသင့် မသုံးသင့်

Multithreading ဆိုတာ ကွန်ပျူတာ ပရိုဂရမ်းမင်း နဲ့ ဆက်နွယ်နေတဲ့ အသုံးအနှုန်း တစ်ခုပါ။ ပရိုဂရမ်တစ်ခုကို တပြိုင်နက်တည်း လမ်းကြောင်း ၂ခု ၃ခု ခွဲပြီး Run တယ်လို့ အရိုးရှင်းဆုံး အဓိပ္ပာယ် ဖွင့်ရမယ် ထင်ပါတယ်။ ကျွန်တော်တို့ ရေးတဲ့ ပရိုဂရမ်မှာ ၁ ခုမကတဲ့ အလုပ်တွေကို တပြိုင်နက်တည်းမှာ လုပ်ချင်တဲ့ အခါမျိုးမှာ ပရိုဂရမ်ကို Threading သုံးပြီး ရေးလေ့ ရှိကြပါတယ်။

ဥပမာ အနေနဲ့ ပြောရရင် ကျွန်တော်တို့ ၁ ကနေ ၃၀၀၀ အထိ ဂဏန်းတွေကို ပရိုဂရမ်တစ်ခု ရေးပြီး ပေါင်းတယ်လို့ ဆိုကြပါစို့။ အဲဒီ ပရိုဂရမ်ကို သမာရိုးကျ နည်းနဲ့ ရေးမယ် ဆိုရင် ၁ နဲ့ ၂ ပေါင်း၊ ရလာဒ်ကို ၃ နဲ့ထပ်ပေါင်း၊ ရလာဒ်ကို ၄ နဲ့ ထပ်ပေါင်း စတာမျိုး ရေးပြီး ၁ ကနေ ၃၀၀၀ အထိ တောက်လျှောက် ပေါင်းသွားလို့ ရပါတယ်။

ဒါပေမယ့် ၁ကနေ ၃၀၀၀ အထိ ပေါင်းတာကို ရိုးရိုးတန်းတန်း မရေးဘဲ Multithreading Model အနေနဲ့ Thread ၃ ခု ခွဲရေးမယ် ဆိုရင်တော့ အောက်က ပုံမှာ ပြထားတဲ့ အတိုင်း ရေးလို့ ရပါတယ်။

Thread ၃ ခု တပြိုင်နက်တည်း အလုပ်လုပ်နေပုံ

Thread တစ်ခုက ၁နဲ့ ၂ ပေါင်းနေတဲ့ အချိန်မှာ နောက်ထပ် Thread တစ်ခုက ၁၀၀၁ နဲ့ ၁၀၀၂ ကို ပေါင်းနေမယ်။ နောက် Thread တစ်ခုက ၂၀၀၁ နဲ့ ၂၀၀၂ ကို ပေါင်းနေမယ် စတာမျိုး ရေးလို့ ရပါတယ်။ နောက်ဆုံးအဆင့်မှာ ပထမဆုံး Thread က ၁ကနေ ၉၉၉ အထိ ပေါင်းလို့ ရတဲ့ ရလာဒ်နဲ့ ၁၀၀၀ နဲ့ ပေါင်းနေတဲ့ အချိန်မှာ ဒုတိယနဲ့ တတိယ Thread တွေက ၁၀၀၁ ကနေ ၁၉၉၉ အထိ ပေါင်းလို့ ရတဲ့ ရလာဒ်ကို ၂၀၀၀ နဲ့ပေါင်းမယ်။ ၂၀၀၁ ကနေ ၂၉၉၉ အထိ ပေါင်းလို့ ရတဲ့ ရလာဒ်ကို ၃၀၀၀ နဲ့ ပေါင်းမယ် စတာမျိုးတွေ လုပ်နေကြမှာ ဖြစ်ပါတယ်။ နောက်မှ အဲဒီ ရလာဒ် သုံးခုကို ပြန်ပေါင်းရင် ၁ ကနေ ၃၀၀၀ အထိ ပေါင်းလို့ ရတဲ့ အဖြေကို ရပါလိမ့်မယ်။

ခုန မော်ဒယ်လ် ၂ ခုကို ယှဉ်ကြည့်ရင် ဒုတိယမြောက် Model က ပိုကောင်းတယ်လို့ ထင်ရပါလိမ့်မယ်။ ဒါပေမယ့် တကယ်တမ်းတော့ မဟုတ်ပါဘူး။ အဲဒီ Model နှစ်ခုကို အချိန်မှတ်ပြီး Run ကြည့်ရင် ပထမ Model က ပိုမြန်တယ် ဆိုတာ တွေ့ရပါလိမ့်မယ်။ အဲဒါ Thread နဲ့ ပတ်သက်ပြီး ပရိုဂရမ်မာ အများစု နားလည်မှု လွဲနေကြတာရဲ့ အဓိက အချက်ပါပဲ။ Threading ဆိုတာ Performance ကောင်းဖို့ အတွက် သုံးတာ မဟုတ်ပါဘူး။ တကယ်တမ်းမှာတော့ Threading သုံးရင်  ပရိုဂရမ်ရဲ့ Performance ကျသွားတတ်ပါတယ်။

ဘာဖြစ်လို့ Performance ကျသွားရတာလဲ ဆိုတာကို ရှင်းပြပါ့မယ်။ အရိုးအရှင်းဆုံး ဥပမာ အနေနဲ့ ခုန Model နှစ်ခုကို Pentium 4 ပရိုဆက်ဆာ တစ်ခု ရှိတဲ့ ကွန်ပျူတာ တစ်လုံးပေါ်မှာ Run တယ်လို့ တွေးကြည့်ကြရအောင်။ ပရိုဆက်ဆာ တစ်ခုဟာ အချိန်တစ်ခု ဒါမှမဟုတ် Time Slice တစ်ခုမှာ အလုပ်တစ်ခုပဲ လုပ်နိုင်ပါတယ်။ ဒါဆိုရင် Thread ၃ ခု အနေနဲ့ ပရိုဆက်ဆာရဲ့ အချိန်ကို ခွဲဝေယူကြဖို့ လိုလာပါပြီ။ အဲဒီ အတွက် Thread ၃ ခု တပြိုင်နက်တည်း အလုပ်လုပ်တယ်လို့ ထင်ရအောင် ပရိုဆက်ဆာရဲ့ ပထမ Cycle မှာ ပထမ Thread က Run၊ နောက် Cycle တစ်ခုမှာ ဒုတိယ Thread က Run၊ နောက် Cycle တစ်ခုမှာ တတိယ Thread က Run၊ ပြီးရင် နောက်ထပ် Cycle တစ်ခုမှာ ပထမ Thread က ပြန် Run ဆိုတဲ့ ပုံစံမျိုး သွားရပါလိမ့်မယ်။

အဲဒီလို လုပ်ဖို့အတွက် ပရိုဆက်ဆာ အနေနဲ့ Thread တစ်ခုနဲ့ တစ်ခု အပြောင်းအလဲ ကြားမှာ အလုပ်ပိုလုပ်ရပါတယ်။ Context Switching လုပ်တယ်လို့ ခေါ်ပါတယ်။ Thread တစ်ခု ကို Run ပြီး နောက်တစ်ခုကို ပြောင်းဖို့ အတွက် အခု လက်ရှိ Run နေတဲ့ Thread နဲ့ သက်ဆိုင်တဲ့ Thread ရဲ့ အခြေအနေ၊ Program Counter စတဲ့ Context လို့ခေါ်တဲ့ အချက်အလက် တွေကို အရင်ဆုံး သိမ်းဆည်းရပါတယ်။ အဲဒီလို သိမ်းပြီးတော့မှ နောက်ထပ် Run မယ့် Thread ရဲ့ အချက်အလက်တွေ ကို ခေါ်ယူရပါတယ်။ ဒီ Thread ကို Run လို့ ပြီးသွားပြီ ဆိုရင် သူနဲ့ ဆိုင်တဲ့ အချက်အလက်တွေကို သိမ်းဆည်းပြီး နောက် Thread ရဲ့ အချက်အလက်တွေ ကို ခေါ်ရပါတယ်။ အဲဒီလို Thread တစ်ခုနဲ့ တစ်ခု အပြောင်းအလဲ ကြားမှာ အလုပ် ပိုလုပ်ရတဲ့ အတွက် ပရိုဆက်ဆာမှာ အချိန် ပိုကုန်ပါတယ်။ အဲဒါကြောင့် Thread ကို သုံးတာကြောင့် ပရိုဂရမ်ရဲ့ Performance တက်မလာဘဲ ကျသွားတယ်လို့ ပြောရတာပါ။

ကျွန်တော် ခုန ဥပမာ ပြသွားခဲ့တာ Pentium 4 ပရိုဆက်ဆာနဲ့ ဥပမာ ပြသွားပါတယ်။ အဲဒါဆိုရင် Pentium 4 လို ပရိုဆက်ဆာ တစ်လုံးတည်း ပါတဲ့ ကွန်ပျူတာမျိုး မဟုတ်ဘဲ Core i7 လို ပရိုဆက်ဆာ တစ်ခုမက ပါတဲ့ ကွန်ပျူတာ မျိုးနဲ့ Run မယ် ဆိုရင်ကော လို့ စောဒက တက်စရာ ရှိလာပါတယ်။ သီအိုရီ အရ ပရိုဆက်ဆာ တစ်ခု မကတဲ့ ကွန်ပျူတာမှာ Thread တွေကို Run မယ်ဆိုရင် ပရိုဆက်ဆာတစ်လုံးတည်းမှာ အလုပ်မလုပ်ဘဲ ပရိုဆက်ဆာတွေ အများကြီးပေါ်မှာ ခွဲဝေပြီး အလုပ်လုပ်တယ်လို့ ဆိုထားပါတယ်။ ဒါပေမယ့်လည်း စဉ်းစားစရာ ရှိလာပါတယ်။ ကွန်ပျူတာပေါ်မှာ Run နေတာ ကိုယ့်ရဲ့ ပရိုဂရမ် တစ်ခုတည်း မဟုတ်ပါဘူး။ တခြား ပရိုဂရမ်တွေလည်း ရှိပါတယ်။ အောက်က ပုံမှာ ကျွန်တော် အခု လက်ရှိ Windows 7 သုံးနေတဲ့ Core i5 ကွန်ပျူတာရဲ့ Task Manager ကို တွေ့ရပါလိမ့်မယ်။

Windows 7 သုံးနေသော Core i5 ပရိုဆက်ဆာ ကွန်ပျူတာ

 

ပုံမှာ ဝိုင်းပြထားတဲ့ နေရာကို ကြည့်မယ် ဆိုရင် အခုလက်ရှိ Thread ပေါင်း ၁၀၀၀ ကျော် တပြိုင်နက်တည်း Run နေတာကို တွေ့ရပါတယ်။ အကယ်၍ ကိုယ့်ရဲ့ ပရိုဂရမ်က Threading သုံးမယ် ဆိုရင် ကိုယ့်ပရိုဂရမ်ထဲမှာ ပါတဲ့ Thread အရေအတွက်က ပရိုဆက်ဆာရဲ့ အရေအတွက်ထက် နည်းနေမယ် ဆိုရင်တောင်မှ တခြား Run နေတဲ့ ပရိုဂရမ်တွေနဲ့ ကွန်ပျူတာက ပေးနိုင်တဲ့ အရင်းအမြစ်ကို ခွဲဝေသုံးစွဲ ရဦးမယ် ဆိုတဲ့ အကြောင်းကို သတိပြုမိဖို့ လိုအပ်ပါလိမ့်မယ်။

ဒါဆိုရင် Threading က မကောင်းဘူးလား မေးစရာ ရှိလာပါပြီ။ Threading ဆိုတာ Performance ကောင်းဖို့ အတွက် သုံးတယ်လို့ အမှတ်မမှားဖို့ပဲ လိုအပ်တာပါ။ ဒါပေမယ့် ကိုယ့်ရဲ့ ပရိုဂရမ်မှာ Responsiveness လိုအပ်တယ် ဆိုရင်တော့ Threading ကို မဖြစ်မနေ သုံးရပါလိမ့်မယ်။ ဥပမာအားဖြင့် ကျွန်တော့်ရဲ့ ပရိုဂရမ်ဟာ ကွန်ပျူတာထဲက လက်ရှိ အချက်အလက်တွေကို ဆာဗာထဲမှာ သွားပြီး ဖြည့်စွက်ဖို့ လိုအပ်မယ်။ တစ်ချိန်တည်းမှာလည်း အသုံးပြုတဲ့ User ကို ဆော့ဖ်ဝဲလ်ထဲမှာ တခြားအလုပ်တွေကို ဆက်လုပ်လို့ ရနေစေချင်တယ် ဆိုတဲ့ အခါမျိုးမှာ Threading ကို သုံးဖို့ လိုအပ်ပါလိမ့်မယ်။ ကွန်ပျူတာထဲက အချက်အလက်ကို ဆာဗာမှာ သွားပြီး Update လုပ်တာကို နောက်ကွယ်ကနေ Background Thread တစ်ခု အနေနဲ့ လုပ်နေပြီး ရှေ့မှာ တခြား Thread တွေက သူ့ဘာသာသူ အလုပ်ဆက်လုပ်နေလို့ ရပါတယ်။ အဲဒါဆိုရင် ပရိုဂရမ်က နောက်ကွယ်မှာ ဆာဗာကို အချက်အလက်တွေ Update လုပ်နေတဲ့ အချိန်မှာ အသုံးပြုတဲ့သူ အနေနဲ့ နောက်ကွယ်မှာ လုပ်နေတာတွေကို သတိမထားမိ လိုက်ဘဲ သူ့ဘာသာသူ ဆော့ဖ်ဝဲလ်ကို ဆက်သုံးလို့ ရနေပါလိမ့်မယ်။

နောက်တစ်ခုကတော့ Parallelism ပါ။ ကိုယ့်ရဲ့ ပရိုဂရမ်ထဲက အစိတ်အပိုင်းတွေဟာ တပြိုက်နက်တည်း အလုပ်လုပ်ဖို့ မဖြစ်မနေ လိုအပ်တဲ့ အချိန်မျိုးမှာ Thread ကို သုံးရပါတယ်။ ဥပမာ အားဖြင့် ပြရရင် ကျွန်တော်တို့ ရေးတဲ့ ပရိုဂရမ် တစ်ခုဟာ ကွန်ယက် ချိတ်ဆက်ထားတဲ့ ဈေးကွက် ၃-၄ ခုမှာ ရှိတဲ့ စတော့ရှယ်ယာ အချက်အလက်တွေကို တပြိုက်နက်တည်း စောင့်ကြည့်ပြီး အသုံးပြုသူကို အမြန်ဆုံး သတင်းပို့ပေးနေရတဲ့ အခြေအနေမျိုးမှာဆိုရင် Thread ၃ ၄ ခုကို တပြိုင်နက်တည်း Run ထားဖို့ လိုအပ်ပါလိမ့်မယ်။ ကျွန်တော်တို့ လက်ရှိရေးနေတဲ့ စက်ကိရိယာနဲ့ ပတ်သက်တဲ့ ဆော့ဖ်ဝဲလိုမျိုး ဂိမ်း ဆော့ဖ်ဝဲလိုမျိုး ဆော့ဖ်ဝဲလ်တွေမှာတော့ Parallelism အတွက် Threading ကို မဖြစ်မနေသုံးရပါတယ်။

ဒါကတော့ Threading သုံးသင့် မသုံးသင့် ဆိုတာနဲ့ ပတ်သက်တဲ့ ကျွန်တော့် အမြင်ပါပဲ။ နိဂုံးချုပ် အနေနဲ့ ပြောရရင် ပရိုဂရမ် တိုင်းမှာ Thread သုံးတာ မကောင်းပါဘူး။ ကိုယ့် ပရိုဂရမ်ရဲ့ လိုအပ်ချက်အရ Thread ကို သုံးသင့်တဲ့ အခြေ အနေ ဖြစ်နေရင်တော့ သုံးရပါလိမ့်မယ်။ နောက်တစ်ခုက Threading သုံးထားတဲ့ ပရိုဂရမ်ကို တော်ရုံတန်ရုံ အတွေ့အကြုံ ရှိတဲ့ ပရိုဂရမ်မာ တစ်ယောက် အနေနဲ့ အမှား ရှာလို့ မလွယ်ပါဘူး။ အဲဒါကြောင့် ကိုယ့်အဖွဲ့ထဲမှာ အတွေ့အကြုံနည်းတဲ့ ပရိုဂရမ်မာတွေ များနေတယ် ဆိုရင် Thread သုံးဖို့ စဉ်းစားသင့်ပါတယ်။ နောင်ကိုလည်း အလျဉ်းသင့်ရင် သင့်သလို Thread Scheduling အကြောင်း၊ Multithreading Program ကို Debugging လုပ်တဲ့ နည်းစနစ်တွေနဲ့ တခြား Thread နဲ့ ပက်သတ်ပြီး သိသင့် သိထိုက်တဲ့ အကြောင်းတွေကို ရေးပါဦးမယ်။