🧕🏽 🌓 👨🏽‍🎨 C ++ में मल्टीथ्रेडिंग के साथ काम करते समय शीर्ष 20 गलतियां और उनसे बचने के तरीके 🤾🏽 👲🏻 🏘️

नमस्कार, हेब्र! मैं आपके ध्यान में देब हलदर द्वारा "टॉप 20 सी ++ मल्टीथ्रेडिंग त्रुटियों और उनसे कैसे बचा जाए" लेख का अनुवाद लाता हूं।

KDPV। फिल्म "द लूप ऑफ टाइम (2012)" का दृश्य

KDPV। फिल्म "द लूप ऑफ टाइम (2012)" का दृश्य

फिल्म "द लूप ऑफ टाइम" से दृश्य (2012)

मल्टीथ्रेडिंग प्रोग्रामिंग में सबसे कठिन क्षेत्रों में से एक है, खासकर सी ++ में। विकास के वर्षों में, मैंने कई गलतियाँ कीं। सौभाग्य से, उनमें से अधिकांश की समीक्षा कोड और परीक्षण द्वारा की गई थी। फिर भी, किसी तरह उत्पादक पर फिसल गया, और हमें ऑपरेटिंग सिस्टम को संपादित करना पड़ा, जो हमेशा महंगा होता है।

इस लेख में, मैंने उन सभी त्रुटियों को वर्गीकृत करने की कोशिश की, जिन्हें मैं संभावित समाधानों के साथ जानता हूं। यदि आप किसी अन्य नुकसान के बारे में जानते हैं, या वर्णित त्रुटियों को हल करने के लिए सुझाव हैं, तो कृपया लेख के तहत अपनी टिप्पणी छोड़ दें।

गलती # 1: एप्लिकेशन से बाहर निकलने से पहले बैकग्राउंड थ्रेड्स का इंतजार करने के लिए जॉइन () का उपयोग न करें

यदि आप स्ट्रीम ( ज्वाइन () ) में शामिल होना भूल जाते हैं या प्रोग्राम समाप्त होने से पहले इसे अलग कर लेते हैं (detach () इसे शामिल नहीं करते), तो इससे दुर्घटना हो जाएगी। (अनुवाद में शामिल होने के संदर्भ में शब्द शामिल होंगे () और अलग करने के संदर्भ में अलग हो जाएंगे () , हालांकि यह पूरी तरह से सही नहीं है। वास्तव में, सम्मिलित हों () वह बिंदु है जिस पर निष्पादन का एक धागा दूसरे के पूरा होने का इंतजार करता है, और कोई जुड़ने या थ्रेड के विलय नहीं होता है। [टिप्पणी अनुवादक])।

नीचे दिए गए उदाहरण में, हम मुख्य सूत्र में थ्रेड t1 के जुड़ने () को निष्पादित करना भूल गए:

#include "stdafx.h"
#include <iostream>
#include <thread>

using namespace std ;

void LaunchRocket ( )
{
cout << "Launching Rocket" << endl ;
}
int main ( )
{
thread t1 ( LaunchRocket ) ;
//t1.join(); // join-
return 0 ;
}

प्रोग्राम क्रैश क्यों हुआ! क्योंकि मुख्य () फ़ंक्शन के अंत में, चर t1 कार्यक्षेत्र से बाहर चला गया और थ्रेड डिस्ट्रक्टर को कहा गया। डिस्ट्रॉक्टर जाँच करता है कि थ्रेड t1 शामिल होने योग्य है या नहीं । एक धागा शामिल होने योग्य है अगर इसे अलग नहीं किया गया है। इस स्थिति में, std :: समाप्ति को इसके विध्वंसक में कहा जाता है। यहाँ क्या है, उदाहरण के लिए, MSVC ++ संकलक करता है।

~thread ( ) _NOEXCEPT
{ // clean up
if ( joinable ( ) )
XSTD terminate ( ) ;
}

कार्य के आधार पर समस्या को ठीक करने के दो तरीके हैं:

1. मुख्य धागे में धागा t1 की कॉल जॉइन () करें :

int main ( )
{
thread t1 ( LaunchRocket ) ;
t1. join ( ) ; // join t1,
return 0 ;
}

2. धारा धारा 1 को मुख्य धारा से अलग करें, इसे "डीमर्लाइज्ड" स्ट्रीम के रूप में काम करना जारी रखने की अनुमति दें:

int main ( )
{
thread t1 ( LaunchRocket ) ;
t1. detach ( ) ; // t1
return 0 ;
}

गलती # 2: पहले से अलग किए गए धागे को संलग्न करने की कोशिश करना

यदि प्रोग्राम के काम के कुछ बिंदु पर आपके पास एक अलग स्ट्रीम है, तो आप इसे वापस मुख्य स्ट्रीम में संलग्न नहीं कर सकते। यह एक बहुत स्पष्ट गलती है। समस्या यह है कि आप स्ट्रीम को अनपिन कर सकते हैं, और फिर कोड की कुछ सौ पंक्तियाँ लिख सकते हैं और इसे पुन: लिखने का प्रयास कर सकते हैं। आखिर कौन याद करता है कि उसने 300 पंक्तियाँ लिखी थीं, है ना?

समस्या यह है कि यह एक संकलन त्रुटि का कारण नहीं होगा, बजाय कार्यक्रम स्टार्टअप पर दुर्घटनाग्रस्त हो जाएगा। उदाहरण के लिए:

#include "stdafx.h"
#include <iostream>
#include <thread>

using namespace std ;

void LaunchRocket ( )
{
cout << "Launching Rocket" << endl ;
}

int main ( )
{
thread t1 ( LaunchRocket ) ;
t1. detach ( ) ;
//..... 100 -
t1. join ( ) ; // CRASH !!!
return 0 ;
}

समाधान हमेशा थ्रेडिंग को जोड़ने के लिए प्रयास करने से पहले जुड़ने योग्य () के लिए थ्रेड की जांच करना है।

int main ( )
{
thread t1 ( LaunchRocket ) ;
t1. detach ( ) ;
//..... 100 -

if ( t1. joinable ( ) )
{
t1. join ( ) ;
}

return 0 ;
}

गलती # 3: गलतफहमी कि std :: धागा :: join () निष्पादन के कॉलिंग थ्रेड को ब्लॉक करता है

वास्तविक अनुप्रयोगों में, आपको अक्सर प्रसंस्करण नेटवर्क I / O के "लंबे समय तक चलने" के संचालन को अलग करना होगा या एक बटन क्लिक करने के लिए उपयोगकर्ता की प्रतीक्षा करनी होगी, आदि। ऐसे वर्कफ़्लोज़ (उदाहरण के लिए, UI रेंडर थ्रेड) के लिए जुड़ने () में कॉल करने से उपयोगकर्ता इंटरफ़ेस लटक सकता है। अधिक उपयुक्त कार्यान्वयन विधियाँ हैं।

उदाहरण के लिए, GUI अनुप्रयोगों में, एक श्रमिक धागा, पूरा होने पर, UI थ्रेड को एक संदेश भेज सकता है। यूआई स्ट्रीम का अपना ईवेंट प्रोसेसिंग लूप होता है जैसे: माउस को हिलाना, कीज़ को दबाना आदि। यह लूप वर्कर थ्रेड्स से संदेश भी प्राप्त कर सकता है और ब्लॉकिंग जॉइन () विधि को कॉल किए बिना उनका जवाब दे सकता है।

इस कारण से, Microsoft से WinRT प्लेटफ़ॉर्म में लगभग सभी उपयोगकर्ता इंटरैक्शन को अतुल्यकालिक बना दिया जाता है, और सिंक्रोनस विकल्प उपलब्ध नहीं होते हैं। ये निर्णय यह सुनिश्चित करने के लिए किए गए थे कि डेवलपर्स एपीआई का उपयोग करेंगे जो सर्वोत्तम संभव उपयोगकर्ता अनुभव प्रदान करता है। आप इस विषय पर अधिक जानकारी के लिए " आधुनिक सी ++ और विंडोज स्टोर एप्स " मैनुअल का उल्लेख कर सकते हैं।

गलती # 4: मान लें कि स्ट्रीम फ़ंक्शन तर्क डिफ़ॉल्ट रूप से संदर्भ द्वारा पारित किए जाते हैं

स्ट्रीम फ़ंक्शन के तर्क डिफ़ॉल्ट रूप से मान द्वारा पास किए जाते हैं। यदि आपको पास किए गए तर्कों में परिवर्तन करने की आवश्यकता है, तो आपको std :: ref () फ़ंक्शन का उपयोग करके संदर्भ द्वारा उन्हें पास करना होगा।

स्पॉइलर के तहत, एक और C ++ 11 आर्टिकल मल्टीपल्रेडिंग ट्यूटोरियल क्यू एंड ए - थ्रेड मैनेजमेंट बेसिक्स (डेब हल्दर) के उदाहरण से गुजरते हुए, उदाहरण के लिए [लगभग]। अनुवादक]।

अधिक जानकारी:

कोड निष्पादित करते समय:

#include "stdafx.h"
#include <string>
#include <thread>
#include <iostream>
#include <functional>

using namespace std ;

void ChangeCurrentMissileTarget ( string & targetCity )
{
targetCity = "Metropolis" ;
cout << " Changing The Target City To " << targetCity << endl ;
}

int main ( )
{
string targetCity = "Star City" ;
thread t1 ( ChangeCurrentMissileTarget, targetCity ) ;
t1. join ( ) ;
cout << "Current Target City is " << targetCity << endl ;

return 0 ;
}

इसे टर्मिनल में प्रदर्शित किया जाएगा:

Changing The Target City To Metropolis
Current Target City is Star City

जैसा कि आप देख सकते हैं, संदर्भ द्वारा स्ट्रीम में कहे गए फ़ंक्शन द्वारा प्राप्त टारगेटिटी वैरिएबल का मान नहीं बदला है।

तर्क का उपयोग करने के लिए std :: ref () का उपयोग करके कोड को फिर से लिखें:

#include "stdafx.h"
#include <string>
#include <thread>
#include <iostream>
#include <functional>

using namespace std ;

void ChangeCurrentMissileTarget ( string & targetCity )
{
targetCity = "Metropolis" ;
cout << " Changing The Target City To " << targetCity << endl ;
}

int main ( )
{
string targetCity = "Star City" ;
thread t1 ( ChangeCurrentMissileTarget, std :: ref ( targetCity ) ) ;
t1. join ( ) ;
cout << "Current Target City is " << targetCity << endl ;

return 0 ;
}

यह उत्पादन होगा:

Changing The Target City To Metropolis
Current Target City is Metropolis

नए थ्रेड में किए गए परिवर्तन मुख्य फ़ंक्शन में घोषित और शुरू में लक्षित लक्ष्य चर के मूल्य को प्रभावित करेंगे।

गलती # 5: एक महत्वपूर्ण अनुभाग (उदाहरण के लिए, एक म्यूटेक्स) के साथ साझा किए गए डेटा और संसाधनों की रक्षा न करें

बहु-थ्रेडेड वातावरण में, आमतौर पर एक से अधिक थ्रेड संसाधनों और साझा किए गए डेटा के लिए प्रतिस्पर्धा करते हैं। अक्सर यह संसाधनों और डेटा के लिए एक अनिश्चित स्थिति की ओर जाता है, सिवाय इसके कि जब उन तक पहुंच कुछ तंत्र द्वारा संरक्षित होती है जो किसी भी समय उन पर संचालन करने के लिए निष्पादन के केवल एक धागे की अनुमति देता है।

नीचे दिए गए उदाहरण में, std :: cout एक साझा संसाधन है जो 6 थ्रेड्स (t1-t5 + main) के साथ काम करता है।

#include "stdafx.h"
#include <iostream>
#include <string>
#include <thread>
#include <mutex>

using namespace std ;

std :: mutex mu ;

void CallHome ( string message )
{
cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;
}

int main ( )
{
thread t1 ( CallHome, "Hello from Jupiter" ) ;
thread t2 ( CallHome, "Hello from Pluto" ) ;
thread t3 ( CallHome, "Hello from Moon" ) ;

CallHome ( "Hello from Main/Earth" ) ;

thread t4 ( CallHome, "Hello from Uranus" ) ;
thread t5 ( CallHome, "Hello from Neptune" ) ;

t1. join ( ) ;
t2. join ( ) ;
t3. join ( ) ;
t4. join ( ) ;
t5. join ( ) ;

return 0 ;
}

यदि हम इस कार्यक्रम को निष्पादित करते हैं, तो हमें निष्कर्ष मिलता है:

Thread 0x1000fb5c0 says Hello from Main/Earth
Thread Thread Thread 0x700005bd20000x700005b4f000 says says Thread Thread Hello from Pluto0x700005c55000Hello from Jupiter says 0x700005d5b000Hello from Moon
0x700005cd8000 says says Hello from Uranus

Hello from Neptune

इसका कारण यह है कि पांच धागे एक साथ यादृच्छिक क्रम में आउटपुट स्ट्रीम तक पहुंच रहे हैं। निष्कर्ष को अधिक विशिष्ट बनाने के लिए, आपको std :: mutex का उपयोग करके साझा संसाधन तक पहुंच की रक्षा करनी चाहिए। बस CallHome () फ़ंक्शन को बदलें ताकि वह std :: cout का उपयोग करने से पहले म्यूटेक्स को पकड़ ले और उसके बाद इसे मुक्त कर दे।

void CallHome ( string message )
{
mu. lock ( ) ;
cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;
mu. unlock ( ) ;
}

गलती # 6: महत्वपूर्ण सेक्शन से बाहर निकलने के बाद लॉक जारी करना न भूलें

पिछले पैराग्राफ में, आपने देखा कि म्यूटेक्स के साथ एक महत्वपूर्ण अनुभाग को कैसे सुरक्षित किया जाए। हालांकि, म्यूटेक्स पर सीधे लॉक () और अनलॉक () विधियों को कॉल करना पसंदीदा विकल्प नहीं है क्योंकि आप आयोजित लॉक को देना भूल सकते हैं। आगे क्या होगा? संसाधन की रिहाई के लिए इंतजार कर रहे सभी अन्य धागे असीम रूप से अवरुद्ध हो जाएंगे और कार्यक्रम लटका सकता है।

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

void CallHome ( string message )
{
mu. lock ( ) ;
cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;
//mu.unlock();
}

निम्नलिखित इस कोड का आउटपुट है - प्रोग्राम क्रैश हो गया, टर्मिनल में एकमात्र संदेश प्रदर्शित करता है, और समाप्त नहीं हुआ:

Thread 0x700005986000 says Hello from Pluto

ऐसी त्रुटियां अक्सर होती हैं, यही वजह है कि म्यूटेक्स से सीधे लॉक () / अनलॉक () विधियों का उपयोग करना अवांछनीय है। इसके बजाय, std :: lock_guard टेम्पलेट क्लास का उपयोग करें, जो लॉक के जीवनकाल को नियंत्रित करने के लिए RAII मुहावरे का उपयोग करता है। जब लॉक_गार्ड ऑब्जेक्ट बनाया जाता है, तो यह म्यूटेक्स को संभालने की कोशिश करता है। जब प्रोग्राम लॉक_गार्ड ऑब्जेक्ट के दायरे को छोड़ देता है, तो विध्वंसक को कहा जाता है, जो म्यूटेक्स को मुक्त करता है।

हम कॉल का उपयोग करते हुए CallHome () फ़ंक्शन को फिर से लिखते हैं :: lock_guard ऑब्जेक्ट:

void CallHome ( string message )
{
std :: lock_guard < std :: mutex > lock ( mu ) ; //
cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;
} // lock_guard

गलती # 7: महत्वपूर्ण खंड का आकार आवश्यकता से अधिक बड़ा करें

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

void CallHome ( string message )
{
std :: lock_guard < std :: mutex > lock ( mu ) ; // , std::cout

ReadFifyThousandRecords ( ) ;

cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;

} // lock_guard mu

ReadFifyThousandRecords () विधि डेटा को संशोधित नहीं करती है। लॉक के तहत इसे निष्पादित करने का कोई कारण नहीं है। यदि यह विधि 10 सेकंड के लिए निष्पादित की जाती है, तो डेटाबेस से 50 हजार पंक्तियों को पढ़ते हुए, अन्य सभी धागे अनावश्यक रूप से इस पूरी अवधि के लिए अवरुद्ध हो जाएंगे। यह कार्यक्रम के प्रदर्शन को गंभीरता से प्रभावित कर सकता है।

इसका सही समाधान यह होगा कि महत्वपूर्ण खंड में केवल std :: cout के साथ काम किया जाए।

void CallHome ( string message )
{
ReadFifyThousandRecords ( ) ; // ..
std :: lock_guard < std :: mutex > lock ( mu ) ; // , std::cout
cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;

} // lock_guard mu

गलती # 8: एक अलग क्रम में कई ताले लेना

यह गतिरोध के सबसे सामान्य कारणों में से एक है, एक ऐसी स्थिति जिसमें थ्रेड्स को अन्य थ्रेड्स द्वारा अवरुद्ध संसाधनों तक पहुंच की प्रतीक्षा के कारण असीम रूप से अवरुद्ध किया जाता है। एक उदाहरण पर विचार करें:

धारा 1	धारा २
ताला ए	ताला बी
// ... कुछ ऑपरेशन	// ... कुछ ऑपरेशन
ताला बी	ताला ए
// ... कुछ अन्य ऑपरेशन	// ... कुछ अन्य ऑपरेशन
अनलॉक बी	अनलॉक करें
अनलॉक करें	अनलॉक बी

एक स्थिति उत्पन्न हो सकती है जिसमें थ्रेड 1 लॉक बी को पकड़ने की कोशिश करेगा और अवरुद्ध हो जाएगा क्योंकि थ्रेड 2 ने पहले ही कब्जा कर लिया है। उसी समय, दूसरा धागा लॉक ए पर कब्जा करने की कोशिश कर रहा है, लेकिन ऐसा नहीं कर सकता, क्योंकि यह पहले धागे द्वारा कब्जा कर लिया गया था। थ्रेड 1 लॉक A को तब तक रिलीज़ नहीं कर सकता, जब तक कि वह B को लॉक न कर दे, आदि। दूसरे शब्दों में, कार्यक्रम जमा देता है।

यह कोड उदाहरण आपको गतिरोध को पुन: उत्पन्न करने में मदद करेगा:

#include "stdafx.h"
#include <iostream>
#include <string>
#include <thread>
#include <mutex>

using namespace std ;

std :: mutex muA ;
std :: mutex muB ;

void CallHome_Th1 ( string message )
{
muA. lock ( ) ;
// -
std :: this_thread :: sleep_for ( std :: chrono :: milliseconds ( 100 ) ) ;
muB. lock ( ) ;

cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;

muB. unlock ( ) ;
muA. unlock ( ) ;
}

void CallHome_Th2 ( string message )
{
muB. lock ( ) ;
// -
std :: this_thread :: sleep_for ( std :: chrono :: milliseconds ( 100 ) ) ;
muA. lock ( ) ;

cout << "Thread " << this_thread :: get_id ( ) << " says " << message << endl ;

muA. unlock ( ) ;
muB. unlock ( ) ;
}

int main ( )
{
thread t1 ( CallHome_Th1, "Hello from Jupiter" ) ;
thread t2 ( CallHome_Th2, "Hello from Pluto" ) ;

t1. join ( ) ;
t2. join ( ) ;

return 0 ;
}

यदि आप इस कोड को चलाते हैं, तो यह क्रैश हो जाएगा। यदि आप थ्रेड विंडो में डीबगर में गहराई से जाते हैं, तो आप देखेंगे कि पहला थ्रेड ( CallHome_Th1 () से कॉल किया गया है) mutex B पर लॉक प्राप्त करने की कोशिश कर रहा है, जबकि थ्रेड 2 ( CallHome_T2 .2 से कॉल किया गया है) mutex को ब्लॉक करने की कोशिश कर रहा है। थ्रेड में से कोई भी नहीं। सफल नहीं हो सकता, जो गतिरोध की ओर जाता है!

(तस्वीर क्लिक करने योग्य है)

आप इसके बारे में क्या कर सकते हैं? सबसे अच्छा समाधान यह होगा कि कोड का पुनर्गठन किया जाए ताकि लॉकिंग लॉक हर बार उसी क्रम में हो।

स्थिति के आधार पर, आप अन्य रणनीतियों का उपयोग कर सकते हैं:

1. संयुक्त रूप से कई तालों को पकड़ने के लिए रैपर क्लास std :: scoped_lock का उपयोग करें:

std :: scoped_lock lock { muA, muB } ;

2. std :: timed_mutex वर्ग का उपयोग करें, जिसमें आप एक टाइमआउट निर्दिष्ट कर सकते हैं, जिसके बाद संसाधन उपलब्ध नहीं होने पर ताला जारी कर दिया जाएगा।

std :: timed_mutex m ;

void DoSome ( ) {
std :: chrono :: milliseconds timeout ( 100 ) ;

while ( true ) {
if ( m. try_lock_for ( timeout ) ) {
std :: cout << std :: this_thread :: get_id ( ) << ": acquire mutex successfully" << std :: endl ;
m. unlock ( ) ;
} else {
std :: cout << std :: this_thread :: get_id ( ) << ": can't acquire mutex, do something else" << std :: endl ;
}
}
}

गलती # 9: एक एसटीडी हड़पने की कोशिश :: म्यूटेक्स लॉक दो बार

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

#include "stdafx.h"
#include <iostream>
#include <thread>
#include <mutex>

std :: mutex mu ;

static int counter = 0 ;

void StartThruster ( )
{
try
{
// -
}
catch ( ... )
{
std :: lock_guard < std :: mutex > lock ( mu ) ;
std :: cout << "Launching rocket" << std :: endl ;
}
}

void LaunchRocket ( )
{
std :: lock_guard < std :: mutex > lock ( mu ) ;
counter ++ ;
StartThruster ( ) ;
}

int main ( )
{
std :: thread t1 ( LaunchRocket ) ;
t1. join ( ) ;
return 0 ;
}

इस समस्या को हल करने के लिए, आपको कोड को इस तरह से सही करना होगा जैसे कि पहले प्राप्त ताले की पुनः प्राप्ति को रोकना है। आप crd solution के रूप में std :: recursive_mutex का उपयोग कर सकते हैं, लेकिन ऐसा समाधान लगभग हमेशा कार्यक्रम के खराब आर्किटेक्चर को इंगित करता है।

गलती # 10: जब std :: परमाणु प्रकार पर्याप्त हैं म्यूटेक्स का उपयोग करें

जब आपको सरल डेटा प्रकारों को बदलने की आवश्यकता होती है, जैसे कि बूलियन मान या पूर्णांक काउंटर, एसटीडी का उपयोग करना : परमाणु आमतौर पर म्यूटेक्स का उपयोग करने से बेहतर प्रदर्शन देगा।

उदाहरण के लिए, निम्न निर्माण का उपयोग करने के बजाय:

int counter ;
...
mu. lock ( ) ;
counter ++ ;
mu. unlock ( ) ;

एक चर को std के रूप में घोषित करना बेहतर है :: परमाणु :

std :: atomic < int > counter ;
...
counter ++ ;

म्यूटेक्स और परमाणु की विस्तृत तुलना के लिए, तुलना देखें : C ++ 11 बनाम एटोमिक्स के साथ लॉकलेस प्रोग्रामिंग म्यूटेक्स और आरडब्ल्यू-ताले »

मिस्टेक # 11: फ्री थ्रेड्स के पूल का उपयोग करने के बजाय सीधे थ्रेड्स की एक बड़ी संख्या बनाएं और नष्ट करें

प्रोसेसर समय के संदर्भ में थ्रेड बनाना और नष्ट करना एक महंगा ऑपरेशन है। एक स्ट्रीम बनाने की कोशिश की कल्पना करें, जबकि सिस्टम कम्प्यूटेशनल रूप से गहन संचालन कर रहा है, उदाहरण के लिए, ग्राफिक्स या कंप्यूटिंग गेम भौतिकी प्रतिपादन। ऐसे कार्यों के लिए अक्सर उपयोग किया जाने वाला दृष्टिकोण पूर्व-आवंटित थ्रेड्स का एक पूल बनाना है जो नियमित कार्यों को संभाल सकता है, जैसे कि डिस्क पर लिखना या प्रक्रिया के पूरे जीवन चक्र में नेटवर्क पर डेटा भेजना।

थ्रेड पूल की तुलना में थ्रेडिंग को नष्ट करने और खुद को नष्ट करने की तुलना में यह है कि आपको थ्रेड ओवरस्क्रिप्शन (एक ऐसी स्थिति जिसमें थ्रेड की संख्या उपलब्ध कोर से अधिक हो और प्रोसेसर समय का एक महत्वपूर्ण हिस्सा स्विचिंग संदर्भों के लिए खर्च होता है) के बारे में चिंता करने की आवश्यकता नहीं है। अनुवादक])। यह सिस्टम के प्रदर्शन को प्रभावित कर सकता है।

इसके अलावा, पूल का उपयोग हमें थ्रेड्स के जीवन चक्र के प्रबंधन के वेदनाओं से बचाता है, जो अंततः कम त्रुटियों के साथ अधिक कॉम्पैक्ट कोड में तब्दील हो जाता है।

थ्रेड पूल को लागू करने वाले दो सबसे लोकप्रिय पुस्तकालय इंटेल थ्रेड बिल्डिंग ब्लॉक्स (TBB) और Microsoft समानांतर पैटर्न लाइब्रेरी (PPL) हैं ।

त्रुटि संख्या 12: पृष्ठभूमि थ्रेड में होने वाले अपवादों को हैंडल न करें

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

#include "stdafx.h"
#include<iostream>
#include<thread>
#include<exception>
#include<stdexcept>

static std :: exception_ptr teptr = nullptr ;

void LaunchRocket ( )
{
throw std :: runtime_error ( "Catch me in MAIN" ) ;
}

int main ( )
{
try
{
std :: thread t1 ( LaunchRocket ) ;
t1. join ( ) ;
}
catch ( const std :: exception & ex )
{
std :: cout << "Thread exited with exception: " << ex. what ( ) << " \n " ;
}

return 0 ;
}

जब इस कार्यक्रम को निष्पादित किया जाता है, तो यह दुर्घटनाग्रस्त हो जाएगा, हालांकि, मुख्य () फ़ंक्शन में कैच ब्लॉक निष्पादित नहीं होगा और थ्रेड टी 1 में फेंके गए अपवाद को संभाल नहीं पाएगा।

इस समस्या का हल C ++ 11 से सुविधाओं का उपयोग करना है: std :: अपवाद_ptr का उपयोग पृष्ठभूमि थ्रेड में फेंके गए अपवाद को संभालने के लिए किया जाता है। ये कदम आपको उठाने होंगे:

Std का एक वैश्विक उदाहरण बनाएँ :: अपवाद_ptr वर्ग को nullptr से आरंभ किया गया
एक फ़ंक्शन के अंदर जो एक अलग थ्रेड में चलता है, सभी अपवादों को संभालता है और वैश्विक चर std :: current_exception () का मान सेट करता है :: अपवाद_ptr पिछले चरण में घोषित
मुख्य धागे के अंदर एक वैश्विक चर के मूल्य की जांच करें
यदि मान सेट है, तो पहले से पकड़े गए अपवाद को बार-बार कॉल करने के लिए std :: rethrow_exception (अपवाद_ptr p) फ़ंक्शन का उपयोग करें, इसे संदर्भ के रूप में एक पैरामीटर के रूप में पास करें

संदर्भ द्वारा एक अपवाद को याद करना उस धागे में नहीं होता है जिसमें इसे बनाया गया था, इसलिए यह सुविधा विभिन्न थ्रेड्स में अपवादों को संभालने के लिए महान है।

नीचे दिए गए कोड में, आप सुरक्षित रूप से पृष्ठभूमि थ्रेड में फेंके गए अपवाद को संभाल सकते हैं।

#include "stdafx.h"
#include<iostream>
#include<thread>
#include<exception>
#include<stdexcept>

static std :: exception_ptr globalExceptionPtr = nullptr ;

void LaunchRocket ( )
{
try
{
std :: this_thread :: sleep_for ( std :: chrono :: milliseconds ( 100 ) ) ;
throw std :: runtime_error ( "Catch me in MAIN" ) ;
}
catch ( ... )
{
//
globalExceptionPtr = std :: current_exception ( ) ;
}
}

int main ( )
{
std :: thread t1 ( LaunchRocket ) ;
t1. join ( ) ;

if ( globalExceptionPtr )
{
try
{
std :: rethrow_exception ( globalExceptionPtr ) ;
}
catch ( const std :: exception & ex )
{
std :: cout << "Thread exited with exception: " << ex. what ( ) << " \n " ;
}
}

return 0 ;
}

गलती # 13: std :: async का उपयोग करने के बजाय, अतुल्यकालिक ऑपरेशन का अनुकरण करने के लिए थ्रेड्स का उपयोग करें

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

Std का उपयोग करने का एक और महत्वपूर्ण लाभ :: async एक एसिंक्रोनस ऑपरेशन का परिणाम प्राप्त करने की क्षमता है std का उपयोग करके कॉलिंग थ्रेड पर वापस लौटना :: भविष्य की वस्तु। कल्पना कीजिए कि हमारे पास एक ConjureMagic () फ़ंक्शन है जो एक इंट रिटर्न देता है। हम एक अतुल्यकालिक ऑपरेशन शुरू कर सकते हैं, जो भविष्य में भविष्य की वस्तु के लिए मूल्य निर्धारित करेगा, जब कार्य पूरा हो जाएगा, और हम निष्पादन के प्रवाह में इस ऑब्जेक्ट से निष्पादन का परिणाम निकाल सकते हैं जिसमें से ऑपरेशन कहा जाता था।

// future
std :: future asyncResult2 = std :: async ( & ConjureMagic ) ;

//... - future

// future
int v = asyncResult2. get ( ) ;

परिणाम को रनिंग थ्रेड से कॉलर पर वापस लाना अधिक बोझिल है। दो तरीके संभव हैं:

आउटपुट चर के संदर्भ को उस स्ट्रीम में पास करना जिसमें यह परिणाम बचाएगा।
परिणाम को वर्कफ़्लो ऑब्जेक्ट के फ़ील्ड चर में संग्रहीत करें, जिसे थ्रेड निष्पादन के पूरा होते ही पढ़ा जा सकता है।

कर्ट गुनथरोथ ने पाया कि प्रदर्शन के मामले में, एक स्ट्रीम बनाने का ओवरहेड 14 बार है जो कि एसिंक्स का उपयोग कर रहा है।

नीचे पंक्ति: std :: async () का उपयोग डिफ़ॉल्ट रूप से तब तक करें जब तक कि आप std का उपयोग करने के पक्ष में मजबूत तर्क न पाएं: सीधे धागा ।

त्रुटि संख्या 14: यदि एसिंक्रोनसी की आवश्यकता है तो std :: launch :: async का उपयोग न करें

Std :: async () फ़ंक्शन सही नाम नहीं है, क्योंकि डिफ़ॉल्ट रूप से यह एसिंक्रोनस रूप से नहीं चल सकता है!

दो std :: async रनटाइम नीतियाँ:

std :: launch :: async : पारित फ़ंक्शन एक अलग थ्रेड में तुरंत निष्पादित करना शुरू करता है
std :: launch :: deferred : पारित फ़ंक्शन तुरंत शुरू नहीं होता है, इसके लॉन्च में देरी होने से पहले () या प्रतीक्षा () कॉल को std :: future object पर किया जाता है, जो std :: async कॉल से वापस आ जाएगी। इन विधियों को कॉल करने के स्थान पर, फ़ंक्शन को सिंक्रनाइज़ रूप से निष्पादित किया जाएगा।

जब हम डिफ़ॉल्ट मापदंडों के साथ std :: async () कॉल करते हैं, तो यह इन दो मापदंडों के संयोजन से शुरू होता है, जो वास्तव में अप्रत्याशित व्यवहार की ओर जाता है। Std का उपयोग करने से जुड़ी कई अन्य कठिनाइयाँ हैं : async () डिफ़ॉल्ट स्टार्टअप नीति के साथ:

स्थानीय प्रवाह चर के लिए सही पहुँच की भविष्यवाणी करने में असमर्थता
एक अतुल्यकालिक कार्य इस तथ्य के कारण बिल्कुल भी शुरू नहीं हो सकता है कि कार्यक्रम निष्पादन के लिए कॉल () और प्रतीक्षा () विधियों को नहीं बुलाया जा सकता है
जब लूप्स में उपयोग किया जाता है, जिसमें बाहर निकलने की स्थिति एसटीडी की उम्मीद करती है: भविष्य की वस्तु तैयार होने के लिए, ये लूप कभी समाप्त नहीं हो सकते, क्योंकि एसटीडी :: async कॉल द्वारा लौटाया गया std :: future लौटाया गया भविष्य।

इन सभी कठिनाइयों से बचने के लिए, हमेशा std :: async with std :: लॉन्च :: async लॉन्च पॉलिसी को कॉल करें।

ऐसा न करें:

// myFunction std::async
auto myFuture = std :: async ( myFunction ) ;

इसके बजाय, यह करें:

// myFunction
auto myFuture = std :: async ( std :: launch :: async , myFunction ) ;

इस बिंदु को स्कॉट मेयर्स की पुस्तक "इफेक्टिव एंड मॉडर्न सी ++" में अधिक विस्तार से माना जाता है।

गलती # 15: कॉल को प्राप्त करना () एक std की विधि :: कोड कोड में भविष्य की वस्तु जिसका निष्पादन समय महत्वपूर्ण है

नीचे दिए गए कोड std से प्राप्त परिणाम को संसाधित करता है: एक अतुल्यकालिक ऑपरेशन की भविष्य की वस्तु। हालांकि, जबकि लूप को तब तक लॉक किया जाएगा जब तक एसिंक्रोनस ऑपरेशन पूरा नहीं हो जाता (इस मामले में, 10 सेकंड के लिए)। यदि आप स्क्रीन पर जानकारी प्रदर्शित करने के लिए इस लूप का उपयोग करना चाहते हैं, तो यह यूजर इंटरफेस को रेंडर करने में अप्रिय देरी पैदा कर सकता है।

#include "stdafx.h"
#include <future>
#include <iostream>

int main ( )
{
std :: future < int > myFuture = std :: async ( std :: launch :: async , [ ] ( )
{
std :: this_thread :: sleep_for ( std :: chrono :: seconds ( 10 ) ) ;
return 8 ;
} ) ;

//
while ( true )
{
//
std :: cout << "Rendering Data" << std :: endl ;
int val = myFuture. get ( ) ; // 10
// - Val
}

return 0 ;
}

नोट : उपरोक्त कोड की एक और समस्या यह है कि यह std का उपयोग करने का प्रयास करता है :: भविष्य की वस्तु दूसरी बार, हालांकि std की स्थिति :: भविष्य की वस्तु लूप के पहले पुनरावृत्ति पर पुनः प्राप्त की गई थी और इसे पुनः प्राप्त नहीं किया जा सका।

सही समाधान यह होगा कि स्टैड की वैधता की जाँच करें :: भविष्य की वस्तु को कॉल करने से पहले () विधि। इस प्रकार, हम अतुल्यकालिक कार्य के पूरा होने को अवरुद्ध नहीं करते हैं और पहले से निकाले गए std :: future object से पूछताछ करने का प्रयास नहीं करते हैं।

यह कोड स्निपेट आपको इसे प्राप्त करने की अनुमति देता है:

#include "stdafx.h"
#include <future>
#include <iostream>

int main ( )
{
std :: future < int > myFuture = std :: async ( std :: launch :: async , [ ] ( )
{
std :: this_thread :: sleep_for ( std :: chrono :: seconds ( 10 ) ) ;
return 8 ;
} ) ;

//
while ( true )
{
//
std :: cout << "Rendering Data" << std :: endl ;

if ( myFuture. valid ( ) )
{
int val = myFuture. get ( ) ; // 10

// - Val
}
}

return 0 ;
}

№16: , , , std::future::get()

कल्पना करें कि हमारे पास निम्नलिखित कोड टुकड़ा है, आपको क्या लगता है कि कॉलिंग std :: future :: get () का परिणाम होगा ? यदि आप मानते हैं कि कार्यक्रम दुर्घटनाग्रस्त हो जाएगा - आप बिल्कुल सही हैं! एसिंक्रोनस ऑपरेशन में फेंका गया अपवाद केवल तब फेंका जाता है जब स्टैड :: फ्यूचर ऑब्जेक्ट पर प्राप्त () विधि को बुलाया जाता है । और यदि प्राप्त () विधि को नहीं बुलाया जाता है, तो अपवाद को नजरअंदाज कर दिया जाएगा और फेंक दिया जाएगा जब std :: future object दायरे से बाहर हो जाता है। यदि आपका एसिंक्रोनस ऑपरेशन एक अपवाद को फेंक सकता है, तो आपको हमेशा एक कोशिश या कैच ब्लॉक में std :: future :: get () कॉल को लपेटना चाहिए । यह कैसे दिख सकता है इसका एक उदाहरण:

#include "stdafx.h"
#include <future>
#include <iostream>

int main ( )
{
std :: future < int > myFuture = std :: async ( std :: launch :: async , [ ] ( )
{
throw std :: runtime_error ( "Catch me in MAIN" ) ;
return 8 ;
} ) ;

if ( myFuture. valid ( ) )
{
int result = myFuture. get ( ) ;
}

return 0 ;
}

#include "stdafx.h"
#include <future>
#include <iostream>

int main ( )
{
std :: future < int > myFuture = std :: async ( std :: launch :: async , [ ] ( )
{
throw std :: runtime_error ( "Catch me in MAIN" ) ;
return 8 ;
} ) ;

if ( myFuture. valid ( ) )
{
try
{
int result = myFuture. get ( ) ;
}
catch ( const std :: runtime_error & e )
{
std :: cout << "Async task threw exception: " << e. what ( ) << std :: endl ;
}
}
return 0 ;
}

№17: std::async,

यद्यपि std :: async () अधिकांश मामलों में पर्याप्त है, ऐसी परिस्थितियाँ हैं जिनमें आपको एक स्ट्रीम में अपने कोड के निष्पादन पर सावधानीपूर्वक नियंत्रण की आवश्यकता हो सकती है। उदाहरण के लिए, यदि आप किसी मल्टीपर्सर सिस्टम (उदाहरण के लिए, Xbox) में एक विशिष्ट प्रोसेसर कोर के लिए एक विशिष्ट थ्रेड को बांधना चाहते हैं।

दिए गए कोड के टुकड़े सिस्टम में 5 वें प्रोसेसर कोर के लिए धागे के बंधन को स्थापित करते हैं। यह मूल_हैंडल () स्टैड :: थ्रेड ऑब्जेक्ट की विधि , और इसे Win32 API स्ट्रीम फ़ंक्शन को पास करने के लिए संभव है । स्ट्रीमिंग Win32 एपीआई के माध्यम से कई अन्य सुविधाएँ प्रदान की जाती हैं जो std :: thread या std :: async () में उपलब्ध नहीं हैं । जब काम के माध्यम से

#include "stdafx.h"
#include <windows.h>
#include <iostream>
#include <thread>

using namespace std ;

void LaunchRocket ( )
{
cout << "Launching Rocket" << endl ;
}

int main ( )
{
thread t1 ( LaunchRocket ) ;

DWORD result = :: SetThreadIdealProcessor ( t1. native_handle ( ) , 5 ) ;

t1. join ( ) ;

return 0 ;
}

std :: async (), ये मूल प्लेटफ़ॉर्म फ़ंक्शन उपलब्ध नहीं हैं, जो इस पद्धति को और अधिक जटिल कार्यों के लिए अनुपयुक्त बनाता है।

एक विकल्प std :: packaged_task बनाना और थ्रेड के गुणों को सेट करने के बाद वांछित निष्पादन थ्रेड में ले जाना है।

गलती # 18: कोर की तुलना में बहुत अधिक "रनिंग" धागे उपलब्ध हैं

वास्तुकला की दृष्टि से, प्रवाह को दो समूहों में वर्गीकृत किया जा सकता है: "रनिंग" और "वेटिंग"।

रनिंग थ्रेड्स उस कर्नेल के प्रोसेसर समय का 100% उपयोग करते हैं, जिस पर वे चल रहे हैं। जब एक से अधिक चलने वाले धागे को एक कोर को आवंटित किया जाता है, तो सीपीयू उपयोग दक्षता ड्रॉप हो जाती है। यदि हम एक प्रोसेसर कोर पर एक से अधिक रनिंग थ्रेड निष्पादित करते हैं, तो वास्तव में एक प्रदर्शन लाभ नहीं मिलता है - वास्तव में, अतिरिक्त संदर्भ स्विच के कारण प्रदर्शन गिरता है।

वेटिंग थ्रेड्स केवल कुछ घड़ी चक्रों का उपयोग करते हैं, जिस पर वे निष्पादित होते हैं, जबकि वे सिस्टम ईवेंट या नेटवर्क I / O, आदि की प्रतीक्षा कर रहे हैं। इस स्थिति में, कर्नेल के अधिकांश उपलब्ध प्रोसेसर समय अप्रयुक्त रहता है। एक प्रतीक्षा धागा डेटा को संसाधित कर सकता है, जबकि अन्य घटनाओं को ट्रिगर करने के लिए इंतजार कर रहे हैं - यही कारण है कि एक वेटिंग थ्रेड को एक कोर में वितरित करना फायदेमंद है। कोर के प्रति कई लंबित थ्रेड्स बहुत अधिक कार्यक्रम प्रदर्शन प्रदान कर सकते हैं।

तो, यह समझने के लिए कि सिस्टम कितने रनिंग थ्रेड का समर्थन करता है? Std :: thread :: hardware_concurrency () विधि का उपयोग करें । यह फ़ंक्शन आमतौर पर प्रोसेसर कोर की संख्या लौटाता है, लेकिन इसमें दो या अधिक तार्किक कोर के रूप में व्यवहार करने वाले कोर को ध्यान में रखा जाता है।हाइपरट्रेडिंग ।

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

गलती # 19: सिंक्रनाइज़ेशन के लिए अस्थिर कीवर्ड का उपयोग करना

अस्थिर कीवर्ड, एक चर के प्रकार को निर्दिष्ट करने से पहले, इस चर परमाणु या थ्रेड पर संचालन को सुरक्षित नहीं बनाता है। आप जो चाहते हैं वह std :: atomic है ।

पर चर्चा देखें stackoverflow जानकारी के लिए।

गलती # 20: लॉक फ्री आर्किटेक्चर का उपयोग करना जब तक कि बिल्कुल आवश्यक न हो

जटिलता में कुछ है जो हर इंजीनियर पसंद करता है। नियमित-तुल्यकालन तंत्रों की तुलना में लॉक-फ्री प्रोग्राम बनाना बहुत लुभावना लगता है जैसे कि म्यूटेक्स, सशर्त चर, अतुल्यकालिक, आदि। हालाँकि, हर अनुभवी C ++ डेवलपर से मैंने एक राय रखने के लिए बात की थी। प्रारंभिक विकल्प के रूप में गैर-लॉकिंग प्रोग्रामिंग का उपयोग एक प्रकार का समय से पहले का अनुकूलन है जो सबसे inopportune क्षण में बग़ल में जा सकता है (अपने ऑपरेटिंग सिस्टम में एक दुर्घटना के बारे में सोचें जब आपके पास पूर्ण ढेर डंप नहीं है!)।

सी ++ में मेरे करियर में, केवल एक ही स्थिति थी जिसमें बिना ताले के कोड के निष्पादन की आवश्यकता थी, क्योंकि हमने सीमित संसाधनों के साथ एक प्रणाली में काम किया था, जहां हमारे घटक में प्रत्येक लेनदेन में 10 से अधिक माइक्रोसेकंड नहीं होने चाहिए।

बिना रुकावट के विकास के दृष्टिकोण को लागू करने के बारे में सोचने से पहले कृपया तीन प्रश्नों के उत्तर दें:

क्या आपने अपने सिस्टम के आर्किटेक्चर को डिजाइन करने की कोशिश की है ताकि उसे सिंक्रोनाइज़ेशन मैकेनिज्म की जरूरत न पड़े? एक नियम के रूप में, सबसे अच्छा सिंक्रनाइज़ेशन सिंक्रनाइज़ेशन की कमी है।
यदि आपको सिंक्रनाइज़ेशन की आवश्यकता है, तो क्या आपने प्रदर्शन विशेषताओं को समझने के लिए अपने कोड को प्रोफाइल किया है? यदि हां, तो क्या आपने अड़चनों को अनुकूलित करने की कोशिश की है?
क्या आप लंबवत पैमाने के बजाय क्षैतिज रूप से स्केल कर सकते हैं?

सारांश में, सामान्य अनुप्रयोग विकास के लिए, कृपया गैर-लॉकिंग प्रोग्रामिंग पर विचार करें, जब आपने अन्य सभी विकल्पों को समाप्त कर दिया हो। इस पर ध्यान देने का एक और तरीका यह है कि यदि आप अभी भी उपरोक्त 19 त्रुटियों में से कुछ बना रहे हैं, तो आपको संभवतः बिना अवरोध के प्रोग्रामिंग से दूर रहना चाहिए।

[से। अनुवादक: इस लेख को तैयार करने में मेरी मदद करने के लिए vovo4K को बहुत-बहुत धन्यवाद ।]

C ++ में मल्टीथ्रेडिंग के साथ काम करते समय शीर्ष 20 गलतियां और उनसे बचने के तरीके