 بسم اللہ الرحمن الرحیم آج ہم موڈیول 161 دیسکس کریں گے موڈیول 161 ہے about tuning the performance with critical sections pin counts جس طرح ہم نے دیکھا ہے کہ مختلف قسم کے synchronization objects ہیں اور ان میں سے کچھ synchronization objects کے overheads کام ہے اور کچھ synchronization کے overheads جویں وہ زاد ہے critical section کبھی ہم نے دیکھا ہے کہ اس کے جو overheads ہیں وہ moderate سے ہیں اس کو مزید optimaize کیا جا سکتا ہے optimaize کرنے کے لیے آپ کو یہ سمجھنا بڑے گا کہ critical section جو ہے وہ work کیس طرح سے کرتا ہے اس کی working کے اندر ایک بڑا ایک important factor ہوتا ہے جس کو کہتے ہیں spin count اور spin count کو آپ fine tune کر کے critical section کو optimaize کر سکتے ہیں firstly critical section جو ہے efficient اس وجہ سے ہے کیونکہ critical section جو ہے یہ user space میں work کرتا ہے یہ kernel space میں نہیں work کرتا ہے اس کو آگے کوئی سسٹم کوال نہیں کرنی پڑتے ہیں اس کی جتنی working ہوتی ہے وہ within the user space ہوتی ہے جو بھی اس کا bit test ہونا ہوتا ہے جس کی base میں وہ decided کرتا ہے کہ lock کرنا ہے یا نہیں کرنا ہے already وہ testing جو ہے وہ user space کے اندر ہوئی ہے اس کے لیے اس کو بھی complicated see corner looted see system call perform نہیں کرنی پڑتی ہے یہ کام instantaneously ہو جاتا ہے اسی وقت ہو جاتا ہے جب آپ critical section کو invoke کرتے ہیں to enter into a critical section on the other hand mutex's جو ہے وہ کیا کرتی ہے mutex's جو ہے وہ کیونکہ وہ kernel کا structure ہے تو وہ a system call perform کرتی ہے اور that system call can there determine ہوتا ہے کہ mutex نے lock کرنا ہے یا نہیں lock کرنا جو بھی situation آپ کے سامنے آتی ہیں and release mutex جو ہے وہ بھی of course اسی طرح سے a system call کے طور پہی work کرتی ہے تو اس وجہ سے میں سمجھا رہا ہے کہ critical section جو ہے وہ faster work کرے گا کیونکہ وہ instantaneously user space کے اندری work کرا اس کے لیوہ جو critical section کو آپ انوک کرتے ہیں critical synchronization کے لیے یا کسی بھی purpose کے لیے تو کیا set of operations ہوتے ہیں ان کو بھی سمجھنا ضروری ہے اس کے اندر spend count کا کیا role ہے اور وہ کیسے important ہے critical section کو optimize کرنے کے لیے تو اس کے لیے دیکھتے ہیں کہ جب بھی کوئی ایک thread جو ہے وہ enter critical section کو call کرتی ہے تو enter critical section کو call کرنے پہ اس کے اندر critical section کے اندر a lock bit ہے وہ lock bit جو ہے وہ test ہوتا ہے اگر تو وہ off ہے اس کا مطلب ہے کہ جی ابھی کوئی بھی وہ critical section کے اندر enter نہیں ہوا کسی بھی thread نے critical section acquire نہیں کیا off on us کا he indicates کرتا ہے تو کیا ہوتا ہے کہ وجہ lock bit ہے اس کو set کر دیا جاتا ہے وہ جو کے ایک atomic operation کی مدس کر کیا جاتا ہے تاکہ بیج میں کسی کسی کسم کی switching نہ ہو سکے اور once وہ set ہو جاتا ہے تو وہ directly critical section کے اندر enter ہو جاتا ہے without any wait operation تو اس وجہ سے کیونکہ یہ سارا کچھ اسی وقت ہو گیا جب آپ نے ap call کیا enter critical section آپ کو کسی چیز کا wait نہیں کرنا پڑا کوئی complicated task نہیں perform کرنا پڑا user space کے اندر رہتے ہی یہ کام ہے ایک دم سے ہو گیا اور ایک ہی دو اندر instruction کی مدسے یہ operation perform ہو گیا اس لیے یہ بہت fast ہے جو اس کے علاوہ جو thread آپ کی run ہو رہی ہے اس کا id اس کے identification کیلئے جو بھی اس کا handle ہوتا وہ critical section کے data structure کے اندر stored ہوتا اور in case of recursion اگر آپ recursively وہ thread اسی function کو پھر سے call کرتی ہے تو وہ پھر سے اس کے لیے ایک اور data structure بنے گا اور اس کے اندر اس کا next جو recursive call اس کا بھی status store ہوتا جائے گا تو recursion کو critical section where sport کرتا ہے یہ بھی ایک important factor سمجھنے کا کیجی recursion کو sport کرتا ہے تو recursion سے relevant وہ overheads critical section کے اندر perform ہوتے ہیں اور in case دوسر سناریو کیا ہوسکتا ہے کہ آپ نے critical section کے اوپر enter critical section API invoke کیا تو already وہ critical section اس کو کسی نے acquire کیا ہوئے تو آپ کو کیا کرنا پڑے گا اس کے پر wait کرنا پڑے گا اس کا جو bit ہے وہ test ہوگا اگر وہ already logged ہے تو اس case کے اندر آپ کا جو آپ کی جو thread ہے وہ ایک tight loop کے اندر enter ہو جائے گے وہ tight loop کیوں اس کو کہا جا رہا ہے کیوں کہ وہ multi processor سسٹم کے اندر جتے ہیں بھی processors ہیں ان تمام processor کو involve کرا ہے اور اس loop کے اندر کیا ہوتا ہے کہ repetitively یہ bit check ہوتا رہے گا اور جو onwards آپ کا آپ کی thread ہے اس کو processor نہیں ملے گا جب تا کہ یہ bit جو ہے clear نہیں ہو جاتا کتنی دفہ اس نے اس کو بار بار چیک کرنے یہ آپ کا spin count بتا ہے گا repetitively کئی دفہ وہ اس کو چیک کرتا ہے اور ایک سیٹن point تا کہ اگر اس کو نہیں yield ہوتا processor تو پھر وہ اس کے لیے آگے ایک system call perform کرتا وہ آپ کو پتا ہے wait for single object wait for single object کو وہ transmit کر دیتا ہے تا کہ آپ یہ thread جو ہے یہ block ہو جائے لیکن اس سے پہلے یہ tight loop کے اس سے repetitively بار بار اس کو چیک کرتا ہے گا اور کتنی دفہ چیک کرے گا جتنا کہ آپ نے spin count specify کیا گا یہاں پہ spin count کی importance ہے اگر آپ کے thread ایسی ہے جو کہ critical section کے لئے بہت minimal processing کریا تب execution جو ہے وہ wait for single object کو transmit کرنے کی ضرورت نہیں ہے تب آپ کا your thread اس کو block ہونے کی ضرورت نہیں ہے when count کے دوران ہی اس کو processor yield ہو جائے گا اور faster بہت ایک faster کوئی switching کرنی کرنی کرنی پڑے گی بہت ای faster manor میں آپ کا your thread وہ onwards continue کرے گا اس کو کوئی زیادہ دیر wait نہیں کرنا پڑے گا زیادہ complicated کسم کی switching perform نہیں کرنی پڑے گی اگر wait for single object call ہوتا تو اس case میں thread کی switching perform ہوتی ہے تو اس کے بھی certain overheads اگر in case آپ کا جو system ہے سنگل processor سسٹم ہے تو اس case میں spend count کا استمال ہی نہیں ہوتا اس case میں simply آپ کا processor وہ block ہو جائے گا اس کو spend کرنے گا spend کی طبی importance ہے جب multi processor سسٹم میں multi processor سسٹم کے اندری وہ bit کو چیک کرتا رے گا اور ایک certain amount تک spend کرے گا جب تک a bit وہ clear نہیں ہو جاتا اور similarly آپ کا leave critical سیکشن ہے وہ کیا کرتا ہے وہ آپ کے lock bit کو clear کر دے گا zero کر دے گا اور پھر leave critical سیکشن جو ہے وہ ساتھ ساتھ آگے ایک system call بھی perform کرے گا جس سے کہ release semaphore کی call ہو گے جس سے کہ execution وہ آگے یہ پتہ سکے کہ یہ اس this thread کو release کر دی ہے آپ کوئی دوسی thread وہ اس کو acquire کر سکتی ہے تو یہ ایک extra processing ہوتی ہے جب leave critical سیکشن cooperation ہوتا ہے تو leave critical سیکشن کے اندر آپ کا کرنن انوال ہو جاتا ہے جبکہ enter critical سیکشن کے اندر اس کی execution بہت fast ہوتی ہے امیدیٹ ہوتی اور اگر spend count کے اندر ہتے رہتے ہی سب کو شاہتا ہے تو آپ کو کوئی extra system call perform کرنے کی ضرورت نہیں پڑتی تو in case of single processor optimal in case of multiple processor system وہ optimal be ہو سکتے ہیں in optimal be ہو سکتے ہیں depending upon the spend count depending upon the number size of processing جو کے اس کے اندر ہوری ہے آپ کی thread کے اندر ہوری ہے critical سیکشن کے اندر ہوری ہے