मल्टी-थ्रेडेड प्रोग्रामिंग के बारे में थोड़ा सा। भाग 1. बुराई का समन्वय करना या न करना

काम पर, मुझे अक्सर अत्यधिक भरी हुई मल्टीथ्रेड या मल्टीप्रोसेस सेवाओं (एप्लिकेशन-, वेब-, इंडेक्स-सर्वर) से निपटना पड़ता है।
काफी दिलचस्प है, लेकिन कभी-कभी कृतघ्न काम इस पूरी अर्थव्यवस्था को अनुकूलित करना है।
ग्राहकों की बढ़ती जरूरतों को अक्सर सिस्टम के लौह घटक को और अधिक आधुनिक के साथ बदलने में असमर्थता पर आराम मिलता है, क्योंकि कंप्यूटर का प्रदर्शन, हार्ड ड्राइव और नेटवर्क की गति को पढ़ना / लिखना क्लाइंट अनुरोधों की तुलना में बहुत धीमी गति से बढ़ता है।
यह शायद ही कभी क्लस्टर नोड्स की संख्या को बढ़ाने में मदद करता है (सिस्टम आमतौर पर वितरित किया जाता है)।
अधिक बार, आपको प्रोफाइलर को चलाना होगा, अड़चनों की तलाश करनी होगी, स्रोत कोड में चढ़ना होगा और उन गलतियों को सुधारना होगा जो सहकर्मियों ने छोड़ी हैं, और कभी-कभी खुद भी, जो कई साल पहले एक पाप है।
सिंक्रनाइज़ेशन से जुड़ी कुछ समस्याएं, मैं यहां बताने की कोशिश करूंगा। यह बहु-थ्रेडेड प्रोग्रामिंग पर एक परिचयात्मक पाठ्यक्रम नहीं होगा - यह माना जाता है कि पाठक थ्रेड और संदर्भ स्विच की अवधारणाओं से परिचित है, और जानता है कि म्यूटेक्स, सेमाफोर आदि क्या हैं।

यह किसी भी डेवलपर के लिए स्पष्ट है, जो "हैलो वर्ल्ड" से कुछ बड़ा डिज़ाइन करने में बहु-सूत्रित है कि पूरी तरह से अतुल्यकालिक कोड बनाना अविश्वसनीय रूप से कठिन है - आपको एक सामान्य चैनल में कुछ लिखने की ज़रूरत है, संरचना को मेमोरी में बदलें (उदाहरण के लिए, हैडर टेबल ट्री को घुमाएं), क्या उठाएं कतार से, आदि।
ऐसी पहुंच को सिंक्रनाइज़ करके, हम कोड के कुछ महत्वपूर्ण अनुभागों के एक साथ निष्पादन को प्रतिबंधित करते हैं। आमतौर पर यह एक है, शायद ही कभी कई धागे (जैसे 1 लेखक / एन पाठक)।
सिंक्रनाइज़ेशन की आवश्यकता निर्विवाद है। अत्यधिक सिंक्रनाइज़ेशन बहुत हानिकारक है - प्रोग्राम का एक टुकड़ा 2 या 3 थ्रेड्स पर अधिक या कम स्मार्ट तरीके से काम करता है, लगभग 5 थ्रेड्स के लिए लगभग "सिंगलथ्रेड" निष्पादित किया जा सकता है, और 20 पर भी लगभग बहुत अच्छा हार्डवेयर बिस्तर पर जाता है।

हालांकि, अभ्यास से पता चलता है कि कभी-कभी निष्पादन का अपर्याप्त सिंक्रनाइज़ेशन एक ही परिणाम की ओर जाता है - सिस्टम चिपक जाता है। यह तब होता है जब समानांतर में निष्पादित कोड होता है, उदाहरण के लिए, एचडीडी (निरंतर तलाश) तक पहुंच, या जब कई मेमोरी के विभिन्न बड़े हिस्से तक पहुंचता है (उदाहरण के लिए, संदर्भ स्विच के साथ स्थायी कैश रीसेट - सीपीयू कैश बस बेवकूफी से गिर जाता है)।

सेमाफोर का उपयोग करें

सेमाफोर का आविष्कार न केवल उन पर ReadWriteMutex निर्माण के निर्माण के लिए किया गया था। समानांतर में निष्पादित कोड के एक टुकड़े में हार्डवेयर पर लोड को कम करने के लिए सेमाफोरस का उपयोग किया जा सकता है और इसका उपयोग किया जाना चाहिए।
एक नियम के रूप में, बहुत से "लाठी" को ठीक किया जा सकता है जो आसानी से कोड को प्रोफाइल करके पाया जा सकता है - जब, थ्रेड की संख्या में वृद्धि के साथ, व्यक्तिगत कार्यों का निष्पादन समय काफ़ी बढ़ जाता है, जबकि अन्य फ़ंक्शन समान या तुलनीय गति से काम करते हैं।

प्रोफाइलर के तीसरे अंक में, आप देख सकते हैं कि कैसे InvalidateIdx पद्धति का निष्पादन समय और, तदनुसार invCI_semaphore semaphore InvalidateIdx विधि invCI_semaphore कॉल से invCI_semaphore होने के बाद, InvalidateCacheIdx विधि बदल invCI_semaphore

 semaphore invCI_semaphore(config.InvCI_Count/* = 5*/); ... int InvalidateCacheIdx() { ... while (...) { cache.SearchL2Index(); invCI_semaphore++; while (cache.InvalidateIdx()) {}; invCI_semaphore--; } ... } 

सेमाफोर का उपयोग करने का यह तरीका काफी सरल है और जरूरी नहीं कि उसे प्रक्रिया की पूरी समझ की आवश्यकता हो, लेकिन इसमें कई कमियां हैं, जिनमें यह तथ्य भी शामिल है कि प्रत्येक ब्लॉक के लिए थ्रेड्स की अधिकतम संख्या सबसे अधिक युद्ध में (उत्पादन में, क्लाइंट सिस्टम पर) चुनी जाएगी - जो हमेशा नहीं होती है अच्छा खाओ लेकिन इस अनुकूलन विधि का बड़ा लाभ निष्पादन योजना को बदलने के बिना, पूरी सेवा के थ्रेड्स की संख्या को जल्दी से बढ़ाने की क्षमता है, अर्थात। लगभग पूरे इंजन को बदलने के बिना - बस बाधाओं में पिछले मूल्य के लिए कुछ सेमाफोर डाल दिया। मैं विचारहीन रूप से सेमाफोर का उपयोग करने का समर्थक नहीं हूं, लेकिन एक अस्थायी समाधान (ग्राहक को आश्वस्त करने के लिए) के रूप में, मैंने इस विधि का उपयोग एक बार से अधिक बार "सही ढंग से" करने के लिए किया, बाद में स्रोत कोड में तल्लीन कर दिया।

प्राथमिकता (प्राथमिकता)

प्राथमिकताएं एक बहुत ही सुविधाजनक तंत्र हैं, जो आवेदन को "हल्का" करने में भी काफी आसान बनाता है। उदाहरण के लिए, यदि सिस्टम लॉग एक अलग स्ट्रीम में लिखे गए हैं, तो इसकी प्राथमिकता को कम करके, आप लॉग-लेवल को कम किए बिना प्रक्रिया को बहुत "सुविधाजनक" कर सकते हैं।
उदाहरण के लिए, निम्न प्रकार के एक डिजाइन का उपयोग किया जा सकता है यदि कई थ्रेड्स के साथ एक पूल विभिन्न प्राथमिकताओं के कार्यों को संसाधित करता है:

 // before doing ... if ( thisThread.pool.count() > 1 && !(currentTaskType in (asap, immediately, now)) ) { thisThread.priority = 2 * thisThread.pool.priority; } else { thisThread.priority = 5 * thisThread.pool.priority; } // do current task ... 

उसी समय, आपको यह समझने की आवश्यकता है कि स्ट्रीम की प्राथमिकता पूरी प्रक्रिया के लिए मान्य है, और न केवल उस पूल के लिए जिसमें यह स्ट्रीम मौजूद है - सावधानी के साथ इसका उपयोग करें।

डिवाइड एट एम्पा (डिवाइड एंड कॉन्कर)

अक्सर, कोड के एक टुकड़े के तत्काल निष्पादन की आवश्यकता नहीं होती है - अर्थात। कुछ कार्य या कार्य का कुछ भाग स्थगित किया जा सकता है। उदाहरण के लिए, लॉग लिखना, विज़िट की गणना करना, कैश को फिर से लिखना आदि।
आप अलग-अलग कार्यों में सिंक्रोनस कोड के टुकड़ों को उजागर करके निष्पादन की गति में काफी वृद्धि कर सकते हैं, और फिर बाद में उन्हें निष्पादित कर सकते हैं (उदाहरण के लिए, तथाकथित पृष्ठभूमि सेवा का उपयोग करके)। यह एक अलग धागा, एक थ्रेड पूल या यहां तक ​​कि एक और उर्फ ​​आरपीसी प्रक्रिया हो सकती है (उदाहरण के लिए, वेबसर्विस के लिए एक अतुल्यकालिक कॉल)। स्वाभाविक रूप से, इस कार्य के कॉल (कतारबद्ध, आदि) का समय लागत निष्पादन की लागत से कम होना चाहिए।
एक अलग लॉग स्ट्रीम के साथ उदाहरण:

 //      : int log(int level, ...) { if (level >= level2log) { logMutex.lock(); try { file.write(...); file.flush(); } finally { logMutex.release(); } } } 

 //  -  : int log(int level, ...) { if (level >= level2log) { // ,     : logQueue.mutex.lock(); logQueue.add(currentThread.id, ...); logQueue.mutex.release(); //  -worker' : logQueue.threadEvent.pulse(); } } // background-logging thread: int logThreadProc() { ... while (true) { //   -   /* 500 ms */    /* 10 */: if ( logQueue.count < config.LogMaxCount /* = 10 */ || (sleepTime = currentTime - lastTime) < config.LogLatency /* = 500 */) { logQueue.threadEvent.wait(config.LogLatency - sleepTime); continue; }; //        : logQueue.mutex.lock(); try { foreach (... in logQueue) { file.write(...); logQueue.delete(...); } } finally { logQueue.mutex.release(); } //    : file.flush(); //  : logQueue.threadEvent.wait(); lastTime = currentTime; } ... } 

इस तरह की एक सरल डिजाइन लॉगिंग की लागत को काफी कम कर सकती है और संदर्भ स्विच के परिणामों को कम कर सकती है, जो व्यावहारिक रूप से log विधि का उपयोग करके थ्रेड्स की संख्या पर निर्भर नहीं करेगी।
यह समझना महत्वपूर्ण है कि अब, लॉगिंग पर अतिरिक्त तर्क को लटकाते हुए, केवल लॉग को सीधे लिखने की धारा लोड होती है। यानी आप हमारे लॉग को जितना चाहें उतना अधिक बुद्धिमान बना सकते हैं - एक उदाहरण के रूप में, लॉजिटेंसी की अवधारणा को पेश करें, कुछ प्रकार के लॉग एनालाइज़र (कुछ ऐसा करें जैसे कि विफल 2ban) या उदाहरण के लिए सभी डीबग संदेशों को सहेजने के लिए उन्हें केवल एक त्रुटि के मामले में लॉग इन करें, TID द्वारा समूह , आदि। - यह सब व्यावहारिक रूप से बाकी धागों को लोड नहीं करेगा।
इसके अलावा, पहली विधि का उपयोग करते समय (संदेश सीधे लॉग फ़ाइल में सिंक्रनाइज़ किया गया है), थ्रेड्स को "समानांतर" कहा जाता है। यानी अधिक सिंक्रनाइज़ेशन ऑब्जेक्ट्स (म्यूटेक्स, क्रिटिकल सेक्शन, वेटिंग इवेंट्स) और एक संदर्भ स्विच की लागत जितनी अधिक होगी, उतनी ही अधिक संभावना है कि इन ऑब्जेक्ट्स से गुजरने वाले सभी थ्रेड्स को क्रमिक रूप से निष्पादित किया जाएगा।
यानी किसी कार्य के बहु-थ्रेडेड निष्पादन की गति दृष्टिकोण या इसके एकल-थ्रेडेड निष्पादन की गति से भी बदतर हो जाती है। लॉक () और रिलीज़ () के बीच के समय को कम करते हुए, कोड एक ही बार में दो दिशाओं में सुधार करता है - यह थ्रेड में स्वयं तेज हो जाता है और प्रक्रिया के "समानांतरकरण" की संभावना कम हो जाती है।
घटनाओं की कतार आयोजित करने के बाद, कभी-कभी अतिरिक्त प्रवाह के निर्माण का सहारा लिए बिना समान निर्माण करना संभव है। उदाहरण के लिए, कुछ क्रियाओं को कतारबद्ध करना ताकि बाद में, उदाहरण के लिए, "निष्क्रिय समय" के दौरान, उन्हें एक ही धागे में, एक के बाद एक निष्पादित करें।
इसे टीसीएल पर आसानी से चित्रित किया जा सकता है:

 ##   /  ... ... ##  counter : set counter [db onecolumn {select cntr from accesslog where userid = $userid}] %>     <%= $counter %> ... <% ##   " access log" in background,    "update idle": after idle UpdateAccess $userid [clock seconds] ## . .... ## -    : proc UpdateAccess {userid lasttime} { db exec {update accesslog set cntr = cntr + 1, lastaccess = $lasttime where userid = $userid} } 

कतार, FIFO, LIFO, और मल्टीथ्रेडिंग

एक कतार, एक डेटा पूल या एक सीरियल बफर का आयोजन करना कोई मुश्किल काम नहीं है, लेकिन आपको यह ध्यान रखना होगा कि मल्टीथ्रेडिंग और अन्य चीजों के बराबर होने के साथ, LIFO कतार को नंबर एक विकल्प बनाया जाना चाहिए (बेशक, यदि कार्यों का अनुक्रम महत्वपूर्ण नहीं है)। कभी-कभी आप LIFO और FIFO को मिला सकते हैं या समूह बना सकते हैं (LIFO तत्वों को छोटी FIFO कतार बना सकते हैं या उदाहरण के लिए अंत से बफर का निर्माण कर सकते हैं, आदि)। ऐसी विकृतियों का अर्थ प्रोसेसर कैश में और आंशिक रूप से मेमोरी के आभासी संगठन में है। यानी संभावना है कि LIFO से अंतिम तत्व अभी भी प्रोसेसर कैश में हैं, समान लंबाई के FIFOs के लिए उसी की संभावना से अतुलनीय रूप से अधिक है।

जीवन उदाहरण - हमारे अपने मेमोरी मैनेजर में, एक हैश टेबल एक ही आकार की मुफ्त वस्तुओं के पूल से आयोजित किया गया था (जिन्हें अक्सर malloc / free कहा जाता है, जानते हैं कि यह क्यों किया जाता है :)। mymalloc सिद्धांत के अनुसार पूल का आयोजन किया गया था - mymalloc फ़ंक्शन ने पहले तत्व को लौटाया, बहुत पहले myfree फ़ंक्शन द्वारा पूल में डाल दिया गया था। वह कारण जिसने डेवलपर को FIFO का उपयोग करने के लिए प्रेरित किया, तो वह myfree के बिंदु पर सरल है - यदि कुछ बेईमान "प्रोग्रामर" कुछ समय के लिए myfree के बाद ऑब्जेक्ट का उपयोग करता है, तो प्रोग्राम संभवतः अधिक समय तक काम करेगा। इसे LIFO के साथ प्रतिस्थापित करने के बाद, संपूर्ण शस्त्रागार (एप्लिकेशन सर्वर) जो सक्रिय रूप से मेमोरी मैनेजर का उपयोग करता है, लगभग 30% तेजी से अर्जित किया गया है।

ReadWriteMutex

बहुत बार, ऑब्जेक्ट को बदलने पर ही सिंक्रनाइज़ेशन आवश्यक है। उदाहरण के लिए, किसी साझा फ़ाइल पर लिखते समय, सूचियों या हैश टेबल की संरचना को बदलते समय आदि। उसी समय, एक नियम के रूप में, यह केवल एक थ्रेड के लिए अनुमत है, और अक्सर यहां तक ​​कि रीडिंग थ्रेड्स अवरुद्ध होते हैं (गंदे पढ़ने और प्रोग्राम को एक अपवाद के साथ क्रैश करने के लिए, जब तक कि परिवर्तन के अंत तक पूरी तरह से वैध नहीं हैं)।
आरडब्ल्यू-म्यूटेक्स का उपयोग करके ऐसी वस्तुओं को लॉक करना अधिक सही है, जहां रीडिंग स्ट्रीम एक-दूसरे को ब्लॉक नहीं करती हैं, और केवल जब रिकॉर्ड लॉक होता है, तो कोड पूरी तरह से सिंक्रनाइज़ किया जाता है (एक थ्रेड द्वारा निष्पादित)।
रीड / राइट-म्यूटेक्स का उपयोग करते समय, आपको हमेशा इस बात का सटीक अंदाजा होना चाहिए कि ऑब्जेक्ट को कैसे पढ़ा जाता है, क्योंकि कुछ मामलों में, पढ़ने के दौरान भी, ऑब्जेक्ट बदल सकता है (उदाहरण के लिए, जब लिखने के बाद इनिशियलाइज़ेशन या रीइंस्ट्रुलेशन के दौरान इंटरनल कैश का निर्माण करते हैं)। इस मामले में, आदर्श API सभी अपवादों के साथ, मल्टीथ्रेडिंग के मामले में, या RW-mutex के संभावित उपयोग को रोकने के लिए, या अपने स्वयं के ब्लॉक को कॉलबैक प्रदान करता है, एपीआई प्रलेखन में अधिक विस्तार से वर्णित है। कुछ आरडब्ल्यू-म्यूटेक्स कार्यान्वयन में, आपको पहले से पता होना चाहिए (म्यूटेक्स को बताएं) पाठक थ्रेड्स की संख्या, कभी-कभी लेखक थ्रेड्स। यह लेखन ताले के विशिष्ट कार्यान्वयन के कारण है (आमतौर पर सेमाफोर का उपयोग किया जाता है)। इन और अन्य सीमाओं के बावजूद, यदि कई पाठक धाराएँ हैं, तो जब भी संभव हो ऐसे म्यूटेक्स पर सिंक्रनाइज़ करने की कोशिश करना उचित है।

प्रलेखन पढ़ें, स्रोत कोड पढ़ें

बहु-थ्रेडेड एप्लिकेशन में उपयोग किए जाने पर किसी विशेष वर्ग या वस्तु के पीछे छिपी हुई अज्ञानता की समस्या, कभी-कभी गलतफहमी। यह मूल तुल्यकालन वस्तुओं के लिए विशेष रूप से सच है। मैं स्पष्ट करने की कोशिश करूंगा कि आरडब्ल्यू-म्यूटेक्स के अनुचित उपयोग के उदाहरण से मेरा क्या मतलब है।
मेरे एक सहकर्मी ने एक बार उचित आरडब्ल्यू-म्यूटेक्स का उपयोग किया था, जो कि सेमाफोरस पर निर्मित था। वह RWMutex वर्ग में पाठक धाराओं की संख्या को गतिशील रूप से स्थानांतरित करने के लिए बहुत आलसी था (उसने सांख्यिकीय रूप से "अधिकतम संभव" मान 500 पर सेट किया) और लेखक स्ट्रीम के लिए निम्न कोड लिखा:

 ... RWMutex mtx(500); ... mtx.lockWrite(); hashTab.add(...); mtx.releaseWrite(); ... 

और एक अच्छे लोड के साथ, सर्वर गहरी द्वि घातुमान में चला गया और हाइबरनेशन में चला गया। बात यह है कि उसने दो गलतियाँ कीं - 500 का स्थैतिक मूल्य लेना और यह समझ में नहीं आया कि इस तरह के आरडब्ल्यू-म्यूटेक्स इस विशेष मंच पर कैसे व्यवहार करेंगे। क्योंकि आरडब्ल्यू-म्यूटेक्स को उचित बनाया गया था - निम्नलिखित के समान कोड का उपयोग किया गया था:

 void RWMutex::lockWrite() { writeMutex.lock(); for (register int i = 0; i < readersCount /*    500 */; i++) readSemaphore++; } void RWMutex::releaseWrite() { if (!f4read) writeMutex.release(); readSemaphore -= readersCount; if (f4read) writeMutex.release(); } 

यह डिज़ाइन, readSemaphore += readersCount बजाय lockWrite बॉडी में लूप में readSemaphore++ वृद्धि के उपयोग के कारण, पाठक और लेखक धाराओं के लिए समान अवसर देता है। शायद वह नहीं जानता था कि इस RWMutex के निर्माण के लिए सेमाफोर वर्ग ने एक क्रॉस-प्लेटफॉर्म लाइब्रेरी का इस्तेमाल किया, जिसने इस विशेष प्लेटफॉर्म के लिए एक सरल कोड तैयार किया जो कुछ इस तरह दिखता था:

 int Semaphore::operator ++() { mutex.lock(); if (sema++ > MaxFlowCount) flowMutex.lock(); mutex.release(); } 

यानी जब hashTab हैश टेबल में 100 मान जोड़े गए थे, उसी समय कई रीडर थ्रेड द्वारा पढ़े जाने के दौरान, हमारे पास 100 * 500 ताले थे (और संदर्भ स्विच के कारण कुछ मिलीसेकेंड अवक्षेपित थे)। इस कहानी में सबसे दिलचस्प बात यह है कि यह आधार वर्ग RWSyncHashTable था, हमारे कोड में हर जगह सक्रिय रूप से उपयोग किया जाता था।
ध्यान रखें: कुछ एपीआई निर्माण पहले से ही सिंक में हो सकते हैं। कभी-कभी यह किसी वस्तु का निर्माता और विध्वंसक भी होता है। इस मामले में, अतिरिक्त सिंक्रनाइज़ेशन अक्सर हानिकारक होता है। यह बस मामला है जब आप दलिया को मक्खन के साथ खराब करते हैं।
स्रोतों को पढ़ें, एपीआई के लिए दस्तावेज देखें - और ऐसी गलतियों से आपको बाईपास करने की अधिक संभावना है।

समकालिक! = प्रतीक्षारत

निष्पादन के सिंक्रनाइज़ेशन का मतलब यह बिल्कुल नहीं है कि हमारी प्रक्रिया केवल वही करती है जो इंतजार करती है। आधुनिक प्रणालियों के अवरुद्ध करने के तरीके काफी लचीले हैं, और आपको निम्नलिखित डिज़ाइन बनाने की अनुमति देते हैं:

 static int mtx_locked = 0; //   - - ,  1 ? while ( mtx_locked || !mtx.lock(config.MaxWaitTime /*  1 ms */) ) { //    -  -  ...  ... processNextRequest(); } //   -  ... mtx_locked++; //  ... processInLock(); // unlock ... mtx_locked--; mtx.release(); 

इस तरह के कोड का उपयोग करने से आप म्यूटेक्स को लॉक करने और बिस्तर पर जाने का इंतजार नहीं कर सकते हैं, लेकिन इस समय कुछ और करने की कोशिश करेंगे। एक समान सिद्धांत पर, हालांकि अक्सर थोड़ा अलग तरह से लागू किया जाता है (कॉलबैक या ईवेंट निष्पादन, ट्रांसेक्शनल नोएट लॉकिंग, प्रति थ्रेड-कैशिंग, आदि), अतुल्यकालिक प्रोग्रामिंग की अवधारणा आधारित है। इस मामले में, आपको एक बहुत ही सरल नियम का पालन करना होगा - "प्रतीक्षा न करें।"
यह उदाहरण संदर्भ स्विच से बचने या कम करने के लिए एक और चाल दिखाता है: यह एक स्थिर चर mtx_locked । यह तकनीक आपको mtx.lock को निष्पादित नहीं करने की अनुमति देती है, यदि यह mtx.lock से mtx.lock ज्ञात है कि कोड अवरुद्ध है ( mtx_locked > 0 ), और हमें निश्चित रूप से जानने की आवश्यकता नहीं है - हम बस कुछ और करते हैं।

यह शायद पहला भाग (बहुत सारे अक्षर) खत्म करने लायक है। अगर कहीं मैंने किसी के लिए पूंजीगत सत्य लिखे हैं, तो मैं आपसे विनम्रतापूर्वक क्षमा करने के लिए कहता हूं - बुराई से नहीं। सुझाव, इच्छा, आलोचना का स्वागत है।

अगले भाग में:

• गतिरोध
• घटनाक्रम; प्रतीक्षा करते समय प्रतिक्रिया;
• डेटा बैंकों में सिंक्रनाइज़ेशन;
• सिस्टमव्यापी तुल्यकालन (क्रॉसप्रोसेस, क्रॉसक्लस्टर)
• अतुल्यकालिक प्रोग्रामिंग;
• साझा किए गए संसाधन
• कचरा, रिहा संसाधन
• स्ट्रीम मॉनिटरिंग, हार्टबिट
• रूपरेखा
• आपकी मर्जी