 بسم اللہ الرحمن الرحیم آجو موڈیول 154 دسکریں گے موڈیول 154 جو ہے یہ سرطن گائیڈ لائنز ہے for using mutex's یا critical sections in your program programming guidelines ہیں کیونکہ of course جب آپ کنکرنسی کے ساتھ دیل کر رہے ہیں تو یہ کافی کرپٹک کسم کی programming ہے اس کے اندر آپ کو کئی دفعہ program کے اندر کوئی ڈھونا کافی ڈیفیکلٹ ہو جاتا ہے اور سب کچھ صحیح لکتے ہوئے بھی آپ کے results صحیح نہیں آ رہے ہوتے اور آپ کو بڑی مشکل سے بڑا پزلنگ ہو جاتا ہے exactly point out کرنا کہ کس وجہ سے error آ رہا تو سرطن گائیڈ لائنز ہیں ان گائیڈ لائنز کو follow کیا جائے ان کو follow کرنے سے جو یہ کنکرنسی related issues ہیں ان کو آپ کافی حب تک minimize کر سکتے ہیں پرسلی ایک سب سے پہلہ issue time out کیا جب آپ weight کو call کرتے ہیں on any object آپ ساتھ ایک time out بھی specify کرتے ہیں اور اگر آپ کوئی time out نہیں specify کرتے تو اس کا مطلب ہے کہ ایک thread جو ہے وہ یہ بھی ہو سکتا ہے کہ indefinitely blocked رہے جب آپ نے infinite like دیا تو اس کا مطلب ہے وہ کبھی بھی time out نہیں کرے گا اور کسی وجہ سے اگر وہ release نہیں ہوتی تو وہ آپ کا program جو ہے وہ indefinitely block ہو جاتا ہے تو programmer کو اس چیز کی care کرنے چاہیے یہ دیکھنا چاہیے کہ وہ program اس طرح سے ہوکے کبھی جو program ہے وہ fail نا کرے اور بالکل stuck نا ہو جائے اور اس کی اپنی completion تک پہن سکے تو آپ کو result دے سکے پھر اسی طرح سے اگر کوئی ایک thread جو ہے جب اپنے critical section کے اندر ہے اور اس دوران وہ terminate ہو جاتی ہے یہ again programming fault آپ کا ظاہر ہوتا ہے کہ کوئی آپ نے اس طرح کے pointers use کیا جس وجہ سے exception آئی اور maybe program terminate ہو گیا لیکن build first اگر وہ critical section کے اندر ہے اور critical section کے دوران وہ اپنے operations کانا تھا اور اس دوران program terminate ہو گیا اب کیا ہوگا اب یہ ہوگا کیوں کہ آپ نے critical section کو acquire کیا ہوا تھا اور critical section کو acquire release کیے بغیر ہی آپ کا program terminate ہو گیا تو اب کوئی بھی دوسری جو thread جو اس critical section کے لیے wait کری ہے وہ thread کبھی بھی اپنی completion تک پہنچ نہیں سکے گی وہ ہمیشان کے لیے indefinitely block ہو جائے گی overall جو system کی performance ہے وہ unstable ہو جائے گی خیر میوٹیکسز کے اندر اس چیز کا way out ہے وہ یہ ہے کہ میوٹیکسز جو ہے اس کے اندر ایک abandonment کا concept ہے کہ اگر ایک process نے mutex کو own کیا ہے اور وہ process کسی وجہ سے terminate ہو جاتا ہے تو وہ mutex abandon ہو جاتی ہے اور automatically signal ہو جاتی ہے لیکن mutex کا abandon ہو جانا during run time یہ شو کرتا ہے کہ آپ کا program کے اندر کسی طرح کا programming fault ہے تو اس کو دیکھنے کی ضرورت ہے کیا سا کیوں ہوا لیکن باقی کی جو threads ہے at least وہ fail نہیں ہوں گی وہ indefinitely block نہیں ہوں گی in case you are using mutex پھر اسی طرح سے اگر آپ نے weight کا construct use کیا اور ساتھ آپ نے time out specify کیا اور build first ایسا ہوتا ہے کہ time out ختم ہو جاتا ہے آپ نے اسے ایک specific time period کا time out specify کیا وہ time period ختم ہو جاتا ہے اب آپ کی execution جو ہے وہ آگے continue کر سکتی ہے لیکن question یہ کہ کیا اب آپ کو اس critical resource کو acquire کرنا چاہیے یا نہیں کرنا چاہیے آپ کو اس critical resource کو acquire نہیں کرنا چاہیے کیونکہ اگر آپ کریں گے تو again conflict سا جائے گا time out کی وجہ سے weight ختم ہونا یہ انڈیگیٹ نہیں کرتا کہ جس resource کیلئے آپ weight کرتے ہیں وہ resource available ہے ہو گیا time out صرف اس پکسل کے لیے رکھا گیا ہے کہ تاکہ آپ کا process وہ recover کر سکتے تو آپ کی programming جو ہے اگر time out کی وجہ سے ختم ہوئے تو اس کے اس میں resource acquire نہیں کرنا چاہیے اس کو کچھ اور کرنا چاہیے atleast وہ program وہ thread جو ہے وہ اپنے آپ کو recover کر سکے پھر جب بھی کوئی ایک mutex ہے اس mutex کو کسی نے own کیا ہوا تو اس دوران کئی ساری thread zone جو کہ اس mutex کیلئے weight کر رہی ہے پھر یہ ہوگا کہ mutex جو ہے وہ critical section سے بہر آئے گے اور جب بہر آئے گے mutex release ہوگی اور پھر کوئی اور اس mutex کو own کر کے اس resource کو acquire کر سکتے اور کئی ساری threads critical section میں جانے کا weight کرنی تھی کونسی specific thread جو ہے وہ now critical section میں جائے گی یہ run time پے یا compile time پے یا design time پے آپ نہیں بتا سکتے یہ operating system نے decided کرنا ہے کیا اس وقت circum chances ہیں کتنی threads ہیں کون کونسی threads ہیں کیا ان کی priorities ہے operating system کیا scheduling policy use کرا یہ operating system نے decided کرنا ہے کہ کونسی threads جو ہے وہ next اس resource کو acquire کرے گی یا اس mutex کو own کرے گی تو program کو اس کے بارے میں کوئی assumption نہیں لے نی چاہیے آپ کتی طور پہ ایسا program نہ بنائیں جو یہ assume کرتاو کہ یہ specific thread جو ہے اس کی باری آئے ایک thread کے complete ہونے کے بعد یا critical section سے نکلنے کے بعد ایک specific thread ہے اس کی باری آئے تو program کو اس طریقہ سے generalize ہونا چاہیے کہ کسی کی باری آسکتی ہے اور اس کے according لی program کو کیا کرنا چاہیے یہ mutex جو ہے وہ کئی ایک mutex جو ہے کئی مختلف threads کے critical section کو کنٹرول کرنے کے لئے ہوتا جو mutex کی correspondence ہے وہ number of threads کے ساتھ نہیں ہے ہر thread کا علاقلک mutex ہوگا اسے نہیں ہے mutex جو ہوتا ہے اس کی correspondence resource کے ساتھ ہے ایک resource ہے اس کو کئی ساری threads use کرنے چاہیے ہیں اور اس resource کو کنٹرول کرنے کے لئے آپ ایک mutex بنائیں گے resource اور mutex کی آپس میں correspondence mutex اور thread کی آپس میں correspondence نہیں ہے کئی ساری threads وہ اس mutex کے اوپر کمپیٹ کریں گے to acquire that single resource تو یہ بڑی important بات ہے سمہنے کے لئے کہ آپ جب بھی ایک thread بنائے وہ thread کے اندر ایک نئی mutex نہ بنا دے ایک mutex ہوگی جس کو کساری threads شیئر کریں گے پھر اس کے لوہ جو آپ کا critical region ہے اس کا سائیز بڑا important ہے کہ آپ نے پہلے mutex کو پر weight call کیا آپ critical region کے اندر اندر ہوگے اور اندر میں جا کہ آپ نے mutex ہو رلیز کرنے critical region کا سائیز بہت زیادہ نہیں ہونا چاہیے کہ پورے کا پورا آپ thread ہے وہی critical section کے اندر کردیں جب جترا زادہ code آپ critical section کے اندر کردیں گے critical region کے اندر کردیں گے اتنی ہی optimization کام ہو جائے گی اتنا ہی کام آپ کو concurrency کا advantage ملے گا کیونکہ جب ایک critical region ہے وہ concurrently execute نہیں ہوتا concurrency یہ جو آپ کے synchronization اور concurrency کے objects ہیں وہ اسی چیز کو enforce کرے ہیں کہ جو critical region ہے وہ concurrently execute نہ ہوں دو threads کے یا دو processes کے critical regions جو ہے وہ concurrently execute نہ ہوں اس لیے critical region کی جو code ہے وہ minimum ہونی چاہیے اس کو maximum زادہ زادہ آپ optimize کرنے کی کوشش کریں کم سے کم code جو ہے وہ critical region کے اندر رکھنے کی کوشش کریں locks کا اس کے اندر کم سے کم استعمال کریں locks جو ہیں وہ اور performance کو degrade کر داتے ہیں تو locks کا استعمال جو ہے اپنے critical region کے اندر یا اپنے programs کے اندر کم سے کم کریں پھر جس طرح ہم نے بات کیا کہ جو mutex ہے اس کی correspondence جو ہے وہ resource کے ساتھ ہے thread کے ساتھ نہیں ہے تو اس لیے اگر آپ کا شیرد resource ہے وہ ایک data structure کے اندر آپ نے شیرد resource رکھا ہوئے تو اسی data structure کے اندر آپ mutex کو بھی رکھ ستے ہیں یہ بھی ایک programming تکنی کے ہی لوگ follow کرتے ہیں کہ جو آپ نے اپنے resource کے لیے data structure بنائے اس resource اس data structure کے اندری ایک field آپ mutex ہی رہتے ہیں اور پھر اس mutex اس field کے طوری اس کو access کرتے ہیں previously ہم نے ایک producer consumer problem کے لئے code لکھی تھی اس کے اندر بھی ہم نے یہی کیا تھا کہ جو ہم نے data structure بنائے تھا اس data structure کے اندری ہم نے اپنا synchronization object place کر دیا تو پھر اس طرح سے invariant property ہوتی ہے invariant property یہ ہوتی ہے کہ وہ ایسی property ہوتی ہے جو within the critical region and outside the critical region unchanged رہتی ہے وہ یہ انشور کرتی ہے کہ آپ کی کنکرنسی جو ہے وہ بالکل صحیح چال رہی ہے جس طرح ہم نے previously کچھ ایسی problems بھی دیکھی نہیں کہ کئی سارے processes are کنکرنلی ران کر رہے ہیں تو ہو سکتا ہے اس کنکرنسی کو اگر آپ نے control نہیں کیا تو in the end ان کے کنکرنلی ران کرنے کی وجہ سے آپ کو end میں result ملے گا وہ accurate نہیں ملے گا وہ expected result نہیں ملے گا invariant کو چیک کر کے آپ یہ دیکھ سکتے ہیں کیا آپ کی کنکرنسی صحیح تری کیسے چال رہی ہے within the critical region invariant or outside the critical region if the invariant remains unchanged i.e. for example آپ کے دو variable ہے اور a should always be is equals to b critical region کے اندر بھی a اور b دونوں برابر تھے critical region سے بھی کے باہر بھی a اور b دونوں برابر ہے تو یہ ایک طرح کی formal یعنی کے check ہے کہ آپ کی کنکرنسی آپ نے کنکرنسی جو ہے وہ صحیح تری کیسے enforce کیا تو آپ invariant کو جب بھی آپ کا critical section end ہوتا ہے تو بالکل اس کے end پہ آپ کیا کر سکتے ہیں invariant کو check کر سکتے ہیں to اس کو insure کرنے کے لیے کہ آپ کا جو critical region کے اندر code کی execution ہوئی ہے وہ بالکل صحیح تری کیسے ہوئی ہے جس طرح آپ expecting بالکل صحیح تری کیسے تو یہ ایک اور آپ کو assurance مل جاتی ہے پھر کوئی complex کسم کی condition آپ بناتے ہیں اور ان condition کے اندر کہیں آپ weight اور release کو use کرتے ہیں تو یہ کرنا بھی غلتا ہے اگر بہت آپ نے complex کسم کی condition بنائیں if else وغیرہ کر کے تو ہو سکتا ہے کہ جو آپ کے program کا structure ہے جو اس کے اندر branches بن رہی ہیں تو اس کے اندر ہو سکتا ہے کہ ہو سکتا ہے کہ اگر weight call ہوا ہے تو ہو سکتا ہے تو کوئی بہت complicated decision logic کے بیج میں آپ اپنے critical section کو نہ رکھیں بالکل simple logic اندر clear weight ہونا چاہیے اور clear release ہونا چاہیے آپ کو پتا چاہ رہا ہوں کہ weight نے ایک دفعہ call ہونا اور ایک دفعہ release ہونا ایک ہی entry ہونا چاہیے ایک release point ہونا چاہیے ایک ہی اس کا entry point ہونا چاہیے pre-maturely کوئی ایسا کوئی ایسا آپ control structure نا استعمال کریں جسے کہ execution وہ pre-maturely end ہو جائے جس طرح سے exit کا استعمال کرتے ہیں ہم عام طور پر اپنے programs کے اندر get return کا استعمال کرتے ہیں تو ایسا کوئی آپ construct نہ use کریں جسے کہ critical region کی execution وہ pre-maturely end ہو جائے جب critical section کے اندر آپ enter ہوں a کی entry point اور اس کا a کی exit point ہونا چاہیے جب enter ہوئے تو اسی exit ایک specific exit point پر جہاں پہ جو بھی آپ کا object اس نے release ہونا اس exit point میں سے ہی آپ نے exit کرنا کوئی beach میں سے exit کرنے کا طریقہ through return یا through exit آپ اس طرح کے طریقے کو استعمال نہ کریں termination handlers کا use کیا سکتا termination handlers finally جو ہم نے جس طرح exception handling اندر دیکھا تھا so finally کلوز کو use کر کے آپ بڑے اچھے طریقے سے mutual exclusion جو ہے اس کو enforce کر سکتے critical region کیوں پر اور اگر کسی وجہ سے بیسے تو آپ نے کوشش کرنے ہیں کہ critical region جو ہے اس کی code کم سے کام ہو لیکن کسی وجہ سے کوئی ایسا logic آپ کا بناتا ہے کہ جی آپ code جو ہے وہ بڑی ہو جاتی ہے تو اس کو simplify کرنے کے لیے آپ ایک function بنالیں اس function کے اندر کو code رکھتے ہیں اور جہاں پہ آپ انٹر کرنے اپنے critical section میں اس وہاں پہ آپ اس کے بعد اس function کو call کریں اور پھر سمپلی exit کر جائیں تاکہ آپ کی code جو ہے وہ اور زیادہ redeval ہو جائیں بڑی simple code ہونی چاہیے ایک entry point ایک exit point کب آپ کو پتا لگ رہا ہے کب enter ہو رہے ہیں جب enter ہو رہے ہیں تو آپ کو یہ بھی کلی پتا چل رہا ہے کہ آپ نے exit کرنے termination handlers کو استعمال کریں اور بیتر ہو جاتا ہے اسے اور کنفرم ہو جاتا ہے جب جس نے terminate ہونا ہے تو پھر ہی اس نے objects کو release کرنا یہ ہمارے پاس کچھ guidelines تھی ان guidelines کو اگر follow کریں تو concurrence جو programs ان کو لکھنے میں آپ کو اسانی ہوگی عام طور پہ جو problems آتی ہیں concurrency کے ساتھ programming کرتے وقت لوگوں کو ان guidelines کو follow کرنے سے وہ problems شاہد آپ کو encounter now