ဥပမာ အနေနဲ့ ပြောရရင် ကျွန်တော်တို့ ၁ ကနေ ၃၀၀၀ အထိ ဂဏန်းတွေကို ပရိုဂရမ်တစ်ခု ရေးပြီး ပေါင်းတယ်လို့ ဆိုကြပါစို့။ အဲဒီ ပရိုဂရမ်ကို သမာရိုးကျ နည်းနဲ့ ရေးမယ် ဆိုရင် ၁ နဲ့ ၂ ပေါင်း၊ ရလာဒ်ကို ၃ နဲ့ထပ်ပေါင်း၊ ရလာဒ်ကို ၄ နဲ့ ထပ်ပေါင်း စတာမျိုး ရေးပြီး ၁ ကနေ ၃၀၀၀ အထိ တောက်လျှောက် ပေါင်းသွားလို့ ရပါတယ်။
ဒါပေမယ့် ၁ကနေ ၃၀၀၀ အထိ ပေါင်းတာကို ရိုးရိုးတန်းတန်း မရေးဘဲ 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 ပရိုဆက်ဆာ ကွန်ပျူတာ |
ဒါဆိုရင် 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 နဲ့ ပက်သတ်ပြီး သိသင့် သိထိုက်တဲ့ အကြောင်းတွေကို ရေးပါဦးမယ်။
2 comments:
I'd like to read more about Threading please bro..
Your post gave me valuable knowledge. Please share your hand-on experiences about requirements, difficulties and troubleshooting in development and implementation programming used in Engineering, if you have time. Thank you.
Post a Comment