Modern C++ on kenji.blog

C++ में मल्टीथ्रेडिंग प्रोग्रामिंग और एसिंक्रोनस प्रोसेसिंग (std::async) का परिचय

Sat, 12 Sep 2026 08:00:00 +0900

आधुनिक सॉफ्टवेयर विकास में, मल्टी-कोर CPU के प्रदर्शन को अधिकतम करने के लिए मल्टीथ्रेडिंग प्रोग्रामिंग आवश्यक है। C++11 से, C++ ने मानक लाइब्रेरी के रूप में मल्टीथ्रेडिंग और एसिंक्रोनस प्रोसेसिंग API (<thread>, <mutex>, <condition_variable>, <future>) पेश किए हैं, जिससे प्लेटफ़ॉर्म-विशिष्ट कोड (जैसे POSIX थ्रेड्स या Windows API) लिखे बिना पोर्टेबल और सुरक्षित कंकरेंट प्रोसेसिंग को लागू करना संभव हो गया है। इसके अलावा, C++14, C++17 और C++20 जैसे क्रमिक संस्करणों के साथ, std::scoped_lock और std::jthread जैसी अधिक सुरक्षित और उन्नत सुविधाएँ जोड़ी गई हैं।

इस लेख में, हम C++ मल्टीथ्रेडिंग प्रोग्रामिंग के मूल सिद्धांतों से लेकर डेटा रेस (data race) को रोकने के लिए सिंक्रोनाइज़ेशन तंत्र, और आधुनिक एसिंक्रोनस प्रोसेसिंग (std::async) के साथ-साथ थ्रेड पूल (thread pool) की अवधारणा को विस्तृत कोड उदाहरणों के साथ अच्छी तरह से समझाएंगे।

1. कंकरेंट प्रोसेसिंग की मूल बातें और एमडाहल का नियम (Amdahl’s Law)

मल्टीथ्रेडिंग का मुख्य उद्देश्य “प्रदर्शन में सुधार” है, लेकिन संपूर्ण प्रोग्राम को समानांतर (parallelize) नहीं किया जा सकता है। यहीं पर एमडाहल का नियम (Amdahl’s Law) महत्वपूर्ण हो जाता है।

एमडाहल का नियम एक मॉडल है जो यह अनुमान लगाता है कि प्रोग्राम के एक हिस्से को समानांतर और तेज़ करने पर संपूर्ण सिस्टम के प्रदर्शन में कितना सुधार होगा।

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

$S(N)$ : सैद्धांतिक अधिकतम स्पीडअप अनुपात
$P$ : संपूर्ण प्रोग्राम का वह भाग जिसे समानांतर किया जा सकता है (0 ≤ $P$ ≤ 1)
$N$ : प्रोसेसर (थ्रेड) की संख्या

यह गणितीय सूत्र जो महत्वपूर्ण तथ्य दिखाता है वह यह है कि, “चाहे आप प्रोसेसर की संख्या $N$ को कितना भी बढ़ा लें, क्रमिक भाग $(1 - P)$ जिसे समानांतर नहीं किया जा सकता, वह एक अड़चन (bottleneck) बन जाता है, और स्पीडअप की एक सीमा होती है।” उदाहरण के लिए, भले ही प्रोग्राम का $90\%$ समानांतर करने योग्य हो ($P = 0.9$), जब तक शेष $10\%$ क्रमिक प्रसंस्करण (serial processing) है, अनंत प्रोसेसर का उपयोग करने पर भी गति केवल अधिकतम $10$ गुना ($S(\infty) = 1 / 0.1$) बढ़ेगी।

इसलिए, C++ में मल्टीथ्रेडिंग प्रोग्रामिंग करते समय, न केवल थ्रेड्स को बढ़ाना आवश्यक है, बल्कि एक ऐसे डिज़ाइन की भी आवश्यकता है जो क्रमिक प्रसंस्करण भागों (जैसे लॉक कंटेंशन (lock contention) और सिंक्रोनाइज़ेशन ओवरहेड) को जितना संभव हो उतना कम कर दे।

2. थ्रेड के मूल सिद्धांत: `std::thread` और `std::jthread` (C++20)

पारंपरिक `std::thread` (C++11)

C++11 में पेश किया गया std::thread, एक नए थ्रेड में फ़ंक्शंस या लैम्ब्डा एक्सप्रेशन को निष्पादित करने के लिए सबसे बुनियादी क्लास है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <thread>

void workerFunction(int id) {
 std::cout << "Worker " << id << " is running on thread "
 << std::this_thread::get_id() << std::endl;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // थ्रेड बनाना और निष्पादन शुरू करना
 std::thread t1(workerFunction, 1);

 // लैम्ब्डा एक्सप्रेशन का उपयोग करके थ्रेड बनाना
 std::thread t2([](int id) {
 std::cout << "Lambda Worker " << id << " is running." << std::endl;
 }, 2);

 // थ्रेड के पूरा होने की प्रतीक्षा करना (join)
 t1.join();
 t2.join();

 std::cout << "All threads completed." << std::endl;
 return 0;
}

std::thread के साथ ध्यान देने वाली बात यह है कि इसके नष्ट होने से पहले join() या detach() को कॉल किया जाना चाहिए। यदि std::thread का डिस्ट्रक्टर (destructor) इनमें से किसी को भी कॉल किए बिना कॉल किया जाता है, तो std::terminate() कॉल हो जाएगा, और प्रोग्राम क्रैश हो जाएगा। अपवाद सुरक्षा (exception safety) सुनिश्चित करने के लिए, RAII पैटर्न का उपयोग करके एक कस्टम रैपर क्लास (wrapper class) बनाना आवश्यक था।

आधुनिक `std::jthread` (C++20)

C++20 में, इन कमियों को दूर करते हुए std::jthread (joining thread) पेश किया गया। std::jthread स्वचालित रूप से अपने डिस्ट्रक्टर में join() को कॉल करता है, जिससे अपवाद (exception) होने पर भी थ्रेड सुरक्षित रूप से पूरा होने की प्रतीक्षा कर सकता है। इसके अलावा, इसमें std::stop_token के माध्यम से थ्रेड्स के लिए एक सहयोगी रद्दीकरण (cooperative cancellation) सुविधा भी है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <iostream>
#include <thread>
#include <chrono>

int main() {
 // C++20: std::jthread
 // पहले तर्क (argument) के रूप में std::stop_token प्राप्त करके रद्दीकरण अनुरोधों का पता लगाया जा सकता है
 std::jthread jt([](std::stop_token stoken) {
 while (!stoken.stop_requested()) {
 std::cout << "Working..." << std::endl;
 std::this_thread::sleep_for(std::chrono::milliseconds(500));
 }
 std::cout << "Stop requested. Exiting thread." << std::endl;
 });

 std::this_thread::sleep_for(std::chrono::seconds(2));

 // स्पष्ट रूप से रद्दीकरण का अनुरोध करना
 jt.request_stop();

 // jthread के डिस्ट्रक्टर में स्वचालित रूप से join हो जाता है, इसलिए मैन्युअल रूप से join() कॉल करने की आवश्यकता नहीं है
 return 0;
}

3. डेटा रेस (Data Race) से बचना और सिंक्रोनाइज़ेशन: म्यूटेक्स (Mutex) और लॉक

जब कई थ्रेड्स एक ही समय में एक ही मेमोरी क्षेत्र (जैसे वेरिएबल) तक पहुँचते हैं, और उनमें से कम से कम एक लिख (write) रहा होता है, तो डेटा रेस (Data Race) होती है। C++ मानक में, डेटा रेस अपरिभाषित व्यवहार (Undefined Behavior) का कारण बनती है। इसे रोकने के लिए, std::mutex का उपयोग करके पारस्परिक बहिष्करण (mutual exclusion) आवश्यक है।

`std::mutex` और `std::lock_guard`

कच्चे (raw) std::mutex::lock() और unlock() को मैन्युअल रूप से कॉल करने की अनुशंसा नहीं की जाती है क्योंकि अपवाद (exception) होने पर unlock() कॉल नहीं हो सकता है, जिससे डेडलॉक (deadlock) का जोखिम होता है। C++ में, हम RAII पैटर्न का उपयोग करके std::lock_guard (C++11) या std::scoped_lock (C++17) का उपयोग करते हैं।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


#include <iostream>
#include <vector>
#include <thread>
#include <mutex>

std::mutex g_mutex;
int g_counter = 0;

void incrementCounter(int iterations) {
 for (int i = 0; i < iterations; ++i) {
 // स्कोप से बाहर निकलने पर स्वचालित रूप से unlock हो जाता है
 std::lock_guard<std::mutex> lock(g_mutex);
 ++g_counter;
 }
}

int main() {
 std::vector<std::thread> threads;
 for (int i = 0; i < 10; ++i) {
 threads.emplace_back(incrementCounter, 10000);
 }

 for (auto& t : threads) {
 t.join();
 }

 std::cout << "Final counter value: " << g_counter << std::endl;
 // उम्मीद के मुताबिक 100000 होगा
 return 0;
}

`std::unique_lock`

std::lock_guard एक साधारण स्कोप-आधारित लॉक है, लेकिन यदि अधिक लचीले नियंत्रण (देरी से लॉक करना, समय-सीमित लॉक, बीच में अनलॉक करना आदि) की आवश्यकता है, तो std::unique_lock का उपयोग किया जाता है। std::condition_variable (जिसे आगे समझाया गया है) के लिए std::unique_lock का होना आवश्यक है।

4. थ्रेड्स के बीच संचार: `std::condition_variable`

“उत्पादक-उपभोक्ता पैटर्न (Producer-Consumer Pattern)” को लागू करने के लिए, जहां एक थ्रेड एक निश्चित शर्त पूरी होने तक प्रतीक्षा करता है, और दूसरा थ्रेड शर्त पूरी होने पर उसे सूचित करता है, हम std::condition_variable का उपयोग करते हैं।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>

std::mutex g_mtx;
std::condition_variable g_cv;
std::queue<int> g_dataQueue;
bool g_isFinished = false;

void producer() {
 for (int i = 1; i <= 5; ++i) {
 std::this_thread::sleep_for(std::chrono::milliseconds(200));
 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_dataQueue.push(i);
 std::cout << "Produced: " << i << std::endl;
 }
 g_cv.notify_one(); // उपभोक्ता (consumer) को सूचित करना
 }

 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_isFinished = true;
 }
 g_cv.notify_one(); // पूर्ण होने की सूचना देना
}

void consumer() {
 while (true) {
 std::unique_lock<std::mutex> lock(g_mtx);
 // शर्त पूरी होने तक प्रतीक्षा करें (कतार खाली नहीं है, या समाप्ति ध्वज (flag) सेट है)
 // स्पूरियस वेकअप (Spurious Wakeup) को रोकने के लिए लैम्ब्डा एक्सप्रेशन के साथ शर्त निर्दिष्ट करें
 g_cv.wait(lock, []{ return !g_dataQueue.empty() || g_isFinished; });

 while (!g_dataQueue.empty()) {
 int val = g_dataQueue.front();
 g_dataQueue.pop();
 // अनलॉक करें और भारी प्रोसेसिंग (यहाँ केवल आउटपुट) करें
 lock.unlock();
 std::cout << "Consumed: " << val << std::endl;
 lock.lock(); // लॉक फिर से प्राप्त करें
 }

 if (g_isFinished && g_dataQueue.empty()) {
 break;
 }
 }
}

int main() {
 std::thread t1(producer);
 std::thread t2(consumer);
 t1.join();
 t2.join();
 return 0;
}

इस उदाहरण में, std::condition_variable::wait थ्रेड को तब तक स्लीप अवस्था में रखता है जब तक कि शर्त पूरी नहीं हो जाती, जिससे CPU संसाधनों की अनावश्यक खपत (व्यस्त लूप / busy loop) से बचा जा सकता है।

5. उच्च-स्तरीय एसिंक्रोनस प्रोसेसिंग: `std::future`, `std::promise`, `std::async`

अब तक चर्चा किए गए std::thread और std::mutex शक्तिशाली हैं, लेकिन वे OS के निम्न-स्तरीय (low-level) थ्रेड तंत्र को सीधे C++ में लाते हैं, जिससे परिणाम प्राप्त करने या अपवादों का प्रचार (exception propagation) करने के लिए कोड बोझिल हो जाता है। यदि आप एक रिटर्न वैल्यू (return value) के साथ कंकरेंट प्रोसेसिंग या उच्च-स्तरीय एसिंक्रोनस प्रोसेसिंग करना चाहते हैं, तो <future> हेडर की सुविधाओं का उपयोग करें।

`std::promise` और `std::future`

std::promise उस पक्ष का प्रतिनिधित्व करता है जो परिणाम “सेट” करता है, और std::future उस पक्ष का प्रतिनिधित्व करता है जो परिणाम “प्राप्त” करता है। ये थ्रेड्स के बीच परिणाम और अपवाद पारित करने के लिए एक सुरक्षित चैनल के रूप में कार्य करते हैं।

`std::async` का उपयोग करके टास्क-आधारित कंकरेंट प्रोसेसिंग

C++ में एसिंक्रोनस कार्यों को निष्पादित करने का सबसे अनुशंसित तरीका std::async का उपयोग करना है। std::async एक कार्य को एसिंक्रोनस रूप से निष्पादित करता है और परिणाम प्राप्त करने के लिए एक std::future लौटाता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#include <iostream>
#include <future>
#include <chrono>

int complexCalculation(int x) {
 std::cout << "Calculation started on thread: "
 << std::this_thread::get_id() << std::endl;
 std::this_thread::sleep_for(std::chrono::seconds(2));
 if (x < 0) {
 throw std::invalid_argument("x must be positive");
 }
 return x * 42;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // बलपूर्वक एक अलग थ्रेड में निष्पादित करने के लिए std::launch::async निर्दिष्ट करें
 std::future<int> resultFuture = std::async(std::launch::async, complexCalculation, 10);

 std::cout << "Main thread is doing other work..." << std::endl;

 try {
 // get() कॉल करने से वर्तमान थ्रेड तब तक ब्लॉक रहेगा जब तक गणना पूरी नहीं हो जाती
 int result = resultFuture.get();
 std::cout << "Result: " << result << std::endl;
 } catch (const std::exception& e) {
 std::cerr << "Exception caught: " << e.what() << std::endl;
 }

 return 0;
}

std::async का व्यवहार नीचे दिए गए अनुक्रम आरेख (sequence diagram) में दिखाया गया है।

sequenceDiagram participant Main as "मुख्य थ्रेड (Main Thread)" participant Async as "std::async वर्कर (std::async Worker)" Main->>Async: "std::async(std::launch::async, ...)" activate Async Note over Main: "अन्य कार्य करें (Do other work...)" Main->>Async: "future.get() (तैयार होने तक ब्लॉक करता है)" Note right of Async: "गणनाएँ (Computations...)" Async-->>Main: "परिणाम लौटाएँ या अपवाद फेंकें (Return Result or Throw Exception)" deactivate Async

std::async के पहले तर्क (argument), लॉन्च पॉलिसी (Launch Policy), के दो प्रकार हैं:

std::launch::async: हमेशा एक नया थ्रेड बनाता है (या थ्रेड पूल से असाइन करता है) और एसिंक्रोनस रूप से निष्पादित करता है।
std::launch::deferred: आलसी मूल्यांकन (Lazy evaluation)। जब future.get() या future.wait() को कॉल किया जाता है, तो यह कॉलिंग थ्रेड में सिंक्रोनस रूप से निष्पादित होता है।

यदि डिफ़ॉल्ट रूप से छोड़ दिया जाता है (निर्दिष्ट नहीं किया गया है), तो यह कार्यान्वयन पर निर्भर (implementation-dependent) होता है, और सिस्टम के लोड की स्थिति के आधार पर कोई एक चुना जाता है। यदि आप एसिंक्रोनस निष्पादन सुनिश्चित करना चाहते हैं, স্ক্রिप्त एसिंक्रोनस निष्पादन सुनिश्चित करना चाहते हैं, तो स्पष्ट रूप से std::launch::async निर्दिष्ट करें।

6. थ्रेड पूल (Thread Pool) की अवधारणा

यदि आप हर बार std::async को कॉल करते हैं, या लूप के भीतर बार-बार std::thread बनाते और नष्ट करते हैं, तो थ्रेड कॉन्टेक्स्ट स्विचिंग और OS संसाधन आवंटन के कारण होने वाला ओवरहेड महत्वपूर्ण हो जाता है। विशेष रूप से जब बड़ी संख्या में छोटे कार्यों (fine-grained tasks) को संसाधित किया जाता है, तो थ्रेड पूल (Thread Pool) का उपयोग आवश्यक है।

थ्रेड पूल एक ऐसा आर्किटेक्चर है जहाँ एप्लिकेशन के स्टार्टअप पर एक निश्चित संख्या में वर्कर (Worker) थ्रेड पहले से बना लिए जाते हैं, कार्यों को एक कतार (Queue) में रखा जाता है, और उपलब्ध वर्कर थ्रेड्स कार्यों को कतार से निकालकर क्रमिक रूप से संसाधित करते हैं।

graph TD Client["क्लाइंट / मुख्य थ्रेड (Client / Main Thread)"] -->|कार्य कतार में डालें (Push Task)| Queue["कार्य कतार (Task Queue)"] Queue -->|कार्य निकालें (Pop Task)| W1["वर्कर थ्रेड 1 (Worker Thread 1)"] Queue -->|कार्य निकालें (Pop Task)| W2["वर्कर थ्रेड 2 (Worker Thread 2)"] Queue -->|कार्य निकालें (Pop Task)| W3["वर्कर थ्रेड N (Worker Thread N)"] W1 --> Exec["निष्पादन और फ्यूचर रिटर्न (Execution & Return Future)"] W2 --> Exec W3 --> Exec

हालांकि C++ मानक लाइब्रेरी (C++23 तक) में एक मानक थ्रेड पूल क्लास नहीं है, लेकिन std::thread, std::mutex, std::condition_variable, std::function, और std::packaged_task को मिलाकर कुछ दर्जन पंक्तियों (lines) में एक कुशल थ्रेड पूल लागू करना संभव है। वास्तविक उत्पादन वातावरण (production environment) में, Boost.Asio के एसिंक्रोनस I/O या थर्ड-पार्टी लाइब्रेरी का उपयोग करना आम बात है।

7. प्रदर्शन (Performance) और स्केलेबिलिटी (Scalability) पर विचार

मल्टीथ्रेडिंग प्रोग्रामिंग में सर्वोत्तम प्रदर्शन प्राप्त करने के लिए, न केवल कोड के समानांतरकरण पर बल्कि हार्डवेयर आर्किटेक्चर पर भी ध्यान देना आवश्यक है।

फॉल्स शेयरिंग (False Sharing): भले ही कई थ्रेड्स अलग-अलग वेरिएबल्स को अपडेट कर रहे हों, यदि वे वेरिएबल्स CPU की एक ही कैश लाइन (cache line - आमतौर पर 64 बाइट्स) में स्थित हैं, तो कैश कोहेरेंसी (cache coherency) बनाए रखने के लिए अनावश्यक मेमोरी सिंक्रोनाइज़ेशन होता है, जिससे प्रदर्शन में भारी गिरावट आती है। इसे रोकने के लिए, alignas स्पेसिफायर (specifier) का उपयोग करके वेरिएबल्स को कैश लाइन की सीमाओं पर संरेखित (align) करना आवश्यक है।
लॉक-फ्री (Lock-Free) और std::atomic: म्यूटेक्स के लॉक/अनलॉक के ओवरहेड से बचने के लिए, <atomic> का उपयोग करके अविभाज्य संचालन (atomic operations, जैसे कि Compare-And-Swap) या लॉक-फ्री डेटा स्ट्रक्चर शुरू करने पर विचार किया जाता है। हालाँकि, इसके लिए मेमोरी ऑर्डर (std::memory_order) की सही समझ की आवश्यकता होती है, और इसे लागू करना बहुत कठिन है। इसलिए, आमतौर पर सावधानीपूर्वक प्रदर्शन मापन (performance measurement) के बाद ही इसे पेश किया जाता है, जब इसकी सख्त आवश्यकता हो।

8. निष्कर्ष

हमने C++ में मल्टीथ्रेडिंग और एसिंक्रोनस प्रोग्रामिंग के बारे में बुनियादी बातों से लेकर C++20 की नवीनतम सुविधाओं तक चर्चा की है। महत्वपूर्ण बिंदु इस प्रकार हैं:

मूल रूप से std::async का उपयोग करें: एकल एसिंक्रोनस कार्यों और परिणाम लौटाने वाले कंकरेंट प्रोसेसिंग के लिए, थ्रेड्स को मैन्युअल रूप से प्रबंधित करने के बजाय सुरक्षित std::async और std::future का उपयोग करें।
थ्रेड प्रबंधन के लिए std::jthread: पृष्ठभूमि में लंबे समय तक चलने वाले थ्रेड्स के लिए, C++20 के std::jthread का उपयोग करें ताकि सुरक्षित समाप्ति प्रक्रिया सुनिश्चित हो सके।
सिंक्रोनाइज़ेशन के लिए RAII का लाभ उठाएं: डेटा रेस को रोकने के लिए म्यूटेक्स लॉक हमेशा std::lock_guard या std::unique_lock के माध्यम से किया जाना चाहिए।
ओवरहेड के प्रति सचेत रहें: थ्रेड्स के अत्यधिक निर्माण से बचें, और यदि आवश्यक हो तो थ्रेड पूल आर्किटेक्चर पेश करें।

कंकरेंट प्रोसेसिंग बग (जैसे डेडलॉक, डेटा रेस) की पुनरावृत्ति (reproducibility) कम होती है और इन्हें डीबग करना सबसे कठिन होता है। थ्रेड सुरक्षा (thread safety) के प्रति हमेशा सचेत रहें और आधुनिक C++ के साथ मजबूत और तेज़ सिस्टम विकास प्राप्त करने के लिए उचित मानक लाइब्रेरी टूल का चयन करें।

मेमोरी लीक को रोकने के लिए स्मार्ट पॉइंटर्स (std::unique_ptr / shared_ptr) का उपयोग गाइड

Sat, 12 Sep 2026 07:00:00 +0900

C++ में मेमोरी प्रबंधन लंबे समय से डेवलपर्स के लिए सबसे बड़ी चुनौतियों में से एक रहा है। मैन्युअल new और delete पर निर्भर पारंपरिक मेमोरी प्रबंधन शैली, मेमोरी लीक, डैंगलिंग पॉइंटर्स और डबल फ्री जैसे गंभीर बग्स का कारण बनती थी। हालाँकि, मॉडर्न C++ (C++11 और उसके बाद) के आगमन के साथ, स्थिति नाटकीय रूप से बदल गई है। इसका मुख्य केंद्र “स्मार्ट पॉइंटर्स (Smart Pointers)” है।

इस लेख में, हम मेमोरी लीक को जड़ से खत्म करने और सुरक्षित तथा कुशल संसाधन प्रबंधन प्राप्त करने के लिए शक्तिशाली उपकरणों, जैसे std::unique_ptr, std::shared_ptr और std::weak_ptr के तंत्र और उन्नत उपयोग तकनीकों के बारे में विस्तार से चर्चा करेंगे। इसमें आंतरिक कार्यान्वयन (कंट्रोल ब्लॉक और एटॉमिक ऑपरेशंस), प्रदर्शन पर प्रभाव, और गणितीय मॉडल का उपयोग करके संदर्भ गणना (reference counting) के सूत्रीकरण पर भी गहराई से बात की जाएगी।

1. परिचय: C++ मेमोरी प्रबंधन का अंधकार युग और मॉडर्न C++ की सुबह

पहले के C++ विकास में, डेवलपर्स खुद ही हीप पर आवंटित मेमोरी को मुक्त करने के लिए जिम्मेदार होते थे।

1
2
3
4
5
6
7
8


void legacy_function() {
 int* ptr = new int(10);
 // ... कुछ प्रक्रिया ...
 if (some_condition) {
 return; // मेमोरी लीक होता है! delete कॉल नहीं किया गया
 }
 delete ptr;
}

ऊपर दिए गए कोड में, यदि कोई अपवाद (exception) आता है या जल्दी रिटर्न होता है, तो delete छोड़ दिया जाता है, जिससे मेमोरी लीक होती है। इसे रोकने के लिए इस्तेमाल होने वाला प्रतिमान “RAII (Resource Acquisition Is Initialization)” है। RAII एक ऐसी तकनीक है जो संसाधन आवंटन को ऑब्जेक्ट के इनिशियलाइज़ेशन (कंस्ट्रक्टर) से और संसाधन की मुक्ति को ऑब्जेक्ट के विनाश (डिस्ट्रक्टर) से जोड़ती है। स्मार्ट पॉइंटर्स, मेमोरी प्रबंधन में इस RAII इडियम को लागू करने वाले मानक लाइब्रेरी क्लास स्टैक हैं।

2. `std::unique_ptr`: शून्य ओवरहेड के साथ विशेष स्वामित्व (Exclusive Ownership)

std::unique_ptr एक स्मार्ट पॉइंटर है जिसका डायनामिक रूप से आवंटित ऑब्जेक्ट्स पर “विशेष स्वामित्व (Exclusive Ownership)” होता है। किसी दिए गए संसाधन का मालिक हमेशा केवल एक ही unique_ptr हो सकता है।

2.1 शून्य ओवरहेड (Zero Overhead) का सिद्धांत

std::unique_ptr का सबसे बड़ा आकर्षण इसका प्रदर्शन है। कस्टम डिलीटर (deleter) के बिना डिफ़ॉल्ट स्थिति में, std::unique_ptr का आकार कच्चे पॉइंटर (Raw Pointer) के बिल्कुल समान होता है। इसमें कोई अनावश्यक सदस्य चर (member variables) नहीं होते हैं, और वर्चुअल फ़ंक्शन का भी उपयोग नहीं किया जाता है। कंपाइलर ऑप्टिमाइज़ेशन के कारण, std::unique_ptr के माध्यम से एक्सेस करने पर कच्चे पॉइंटर के समान असेंबली कोड उत्पन्न होता है।

2.2 स्वामित्व का स्थानांतरण और `std::move`

विशेष स्वामित्व होने के कारण, std::unique_ptr को कॉपी नहीं किया जा सकता (कॉपी कंस्ट्रक्टर और कॉपी असाइनमेंट ऑपरेटर delete कर दिए गए हैं)। स्वामित्व को दूसरे unique_ptr में स्थानांतरित करने के लिए, std::move का उपयोग करके मूव सेमांटिक्स (Move Semantics) का उपयोग किया जाता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <memory>

class Resource {
public:
 Resource() { std::cout << "Resource acquired\n"; }
 ~Resource() { std::cout << "Resource destroyed\n"; }
 void do_something() { std::cout << "Doing something\n"; }
};

void process_resource(std::unique_ptr<Resource> ptr) {
 ptr->do_something();
 // स्कोप से बाहर निकलने पर ptr नष्ट हो जाता है, और Resource भी मुक्त हो जाता है
}

int main() {
 std::unique_ptr<Resource> my_ptr = std::make_unique<Resource>();

 // process_resource(my_ptr); // त्रुटि: कॉपी नहीं किया जा सकता
 process_resource(std::move(my_ptr)); // स्वामित्व का स्थानांतरण

 if (!my_ptr) {
 std::cout << "my_ptr is now empty.\n";
 }
 return 0;
}

नीचे दिया गया Mermaid आरेख std::move का उपयोग करके स्वामित्व के स्थानांतरण की अवधारणा को दर्शाता है।

2.3 कस्टम डिलीटर (Custom Deleter) का कार्यान्वयन

C भाषा के लिगेसी API (जैसे FILE* या सॉकेट) को रैप करते समय, मेमोरी को मुक्त करने के लिए delete के अलावा अन्य कार्यों (जैसे fclose) को कॉल करना आवश्यक हो सकता है। std::unique_ptr के दूसरे टेम्प्लेट आर्गुमेंट के रूप में कस्टम डिलीटर निर्दिष्ट किया जा सकता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <cstdio>
#include <memory>

// कस्टम डिलीटर के लिए फनक्टर (Functor)
struct FileDeleter {
 void operator()(FILE* fp) const {
 if (fp) {
 std::cout << "Closing file.\n";
 std::fclose(fp);
 }
 }
};

using UniqueFile = std::unique_ptr<FILE, FileDeleter>;

int main() {
 UniqueFile file(std::fopen("test.txt", "w"));
 if (file) {
 std::fputs("Hello, Smart Pointers!", file.get());
 }
 // स्कोप समाप्त होने पर FileDeleter कॉल किया जाता है और fclose हो जाता है
 return 0;
}

यदि कस्टम डिलीटर के रूप में फ़ंक्शन पॉइंटर या लैम्ब्डा एक्सप्रेशन का उपयोग किया जाता है, तो unique_ptr का आकार बढ़ सकता है, लेकिन जैसा कि ऊपर दिखाया गया है, स्टेटलेस फ़ंक्शन ऑब्जेक्ट (Functor) का उपयोग करने से C++ के EBCO (Empty Base Class Optimization) या C++20 के [[no_unique_address]] के कारण इसका आकार कच्चे पॉइंटर से अधिक नहीं बढ़ता है (शून्य ओवरहेड बना रहता है)।

3. `std::shared_ptr`: साझा स्वामित्व (Shared Ownership) और कंट्रोल ब्लॉक

std::shared_ptr एक स्मार्ट पॉइंटर है जिसका उपयोग कई पॉइंटर्स द्वारा एक ही ऑब्जेक्ट के स्वामित्व को साझा करने के लिए किया जाता है। जब अंतिम shared_ptr नष्ट हो जाता है, तो इसके द्वारा प्रबंधित ऑब्जेक्ट मुक्त हो जाता है।

3.1 आंतरिक आर्किटेक्चर: कंट्रोल ब्लॉक

std::shared_ptr प्रबंधित ऑब्जेक्ट के पॉइंटर के अलावा, हीप पर कंट्रोल ब्लॉक (Control Block) नामक मेटाडेटा आवंटित करता है और उसे साझा करता है। कंट्रोल ब्लॉक में निम्नलिखित जानकारी शामिल होती है:

Strong Count (मजबूत संदर्भ गणना): ऑब्जेक्ट का स्वामित्व रखने वाले shared_ptr की संख्या। जब यह 0 हो जाता है, तो ऑब्जेक्ट नष्ट हो जाता है।
Weak Count (कमजोर संदर्भ गणना): ऑब्जेक्ट की निगरानी करने वाले weak_ptr की संख्या। जब Strong Count और Weak Count दोनों 0 हो जाते हैं, तो कंट्रोल ब्लॉक स्वयं मुक्त हो जाता है।
कस्टम डिलीटर और एलोकेटर (यदि निर्दिष्ट हो)।

इस कारण से, std::shared_ptr ऑब्जेक्ट का आकार आमतौर पर कच्चे पॉइंटर से दोगुना (ऑब्जेक्ट की ओर पॉइंटर और कंट्रोल ब्लॉक की ओर पॉइंटर) होता है।

3.2 प्रदर्शन और एटॉमिक ऑपरेशंस (Atomic Operations)

कंट्रोल ब्लॉक के भीतर संदर्भ गणना (reference count) को एटॉमिक ऑपरेशंस (Atomic Operations) के रूप में लागू किया जाता है, ताकि मल्टीथ्रेडेड वातावरण में भी इसे सुरक्षित रूप से बढ़ाया या घटाया जा सके।

x86/x64 आर्किटेक्चर में, संदर्भ गणना को बढ़ाने या घटाने के लिए lock xadd जैसे एटॉमिक निर्देशों का उपयोग किया जाता है। इसमें सामान्य पूर्णांक जोड़ (integer addition) की तुलना में दर्जनों साइकिलों का ओवरहेड होता है। इसलिए, यदि shared_ptr को फ़ंक्शन में मान द्वारा (by value) पास किया जाता है, तो प्रत्येक कॉपी पर एटॉमिक इंक्रीमेंट और डिक्रीमेंट होता है, जिससे प्रदर्शन में कमी आती है।

सर्वोत्तम अभ्यास (Best Practice): shared_ptr को फ़ंक्शन में पास करते समय, जब तक कि स्वामित्व साझा करना आवश्यक न हो, इसे const std::shared_ptr<T>& (const संदर्भ) के रूप में पास करना चाहिए, या कच्चा पॉइंटर/संदर्भ (raw pointer/reference) पास करना चाहिए।

3.3 `std::make_shared` vs `new`

shared_ptr बनाते समय, जहाँ तक संभव हो std::make_shared का उपयोग करना चाहिए। इसके दो प्रमुख कारण हैं:

मेमोरी आवंटन का अनुकूलन: new का उपयोग करने पर, ऑब्जेक्ट और कंट्रोल ब्लॉक के लिए हीप आवंटन (heap allocation) दो बार होता है। std::make_shared का उपयोग करने पर, दोनों को समाहित करने वाला एक बड़ा मेमोरी ब्लॉक एक ही हीप आवंटन में सुरक्षित किया जा सकता है, जिससे कैश दक्षता (cache efficiency) भी बढ़ती है।
अपवाद सुरक्षा (Exception Safety): C++17 से पहले के मानकों में, फ़ंक्शन के तर्कों (arguments) के मूल्यांकन का क्रम अनिर्दिष्ट (unspecified) था, इसलिए new द्वारा आवंटित पॉइंटर को shared_ptr के कंस्ट्रक्टर में पास करने से पहले यदि अन्य तर्कों के मूल्यांकन के दौरान कोई अपवाद आता, तो मेमोरी लीक का जोखिम होता था। make_shared इस समस्या से पूरी तरह बचाता है।

1
2
3
4
5


// बचने योग्य तरीका (2 बार मेमोरी आवंटन)
std::shared_ptr<MyClass> ptr1(new MyClass());

// अनुशंसित तरीका (1 बार मेमोरी आवंटन)
std::shared_ptr<MyClass> ptr2 = std::make_shared<MyClass>();

4. `std::weak_ptr`: सर्कुलर रेफरेंस (Circular References) का समाधान और निगरानी

साझा स्वामित्व की एक बड़ी कमजोरी “सर्कुलर रेफरेंस (Circular References)” है। यदि ऑब्जेक्ट A और ऑब्जेक्ट B एक-दूसरे को shared_ptr द्वारा इंगित कर रहे हैं, तो प्रत्येक का Strong Count कम से कम 1 पर बना रहता है, और प्रोग्राम समाप्त होने तक यह कभी 0 नहीं होता, जिससे मेमोरी लीक होती है।

graph TD subgraph "सर्कुलर रेफरेंस (Memory Leak)" A["ऑब्जेक्ट A"] -->|"shared_ptr (Strong=1)"| B["ऑब्जेक्ट B"] B -->|"shared_ptr (Strong=1)"| A end

4.1 `std::weak_ptr` द्वारा चक्र (Cycle) को तोड़ना

इस समस्या का समाधान std::weak_ptr है। weak_ptr को shared_ptr से बनाया जाता है और यह ऑब्जेक्ट को संदर्भित करता है, लेकिन यह Strong Count को नहीं बढ़ाता है। इसके बजाय, यह Weak Count को बढ़ाता है। इससे स्वामित्व के बिना ऑब्जेक्ट की “निगरानी” की जा सकती है।

graph TD subgraph "सर्कुलर रेफरेंस को तोड़ना" C["ऑब्जेक्ट A"] -->|"shared_ptr (Strong=1)"| D["ऑब्जेक्ट B"] D -.->|"weak_ptr (Weak=1)"| C end

4.2 `lock()` मेथड के माध्यम से सुरक्षित एक्सेस

weak_ptr के पास सीधे ऑब्जेक्ट तक पहुँचने वाले ऑपरेटर (-> या *) नहीं होते हैं। ऐसा इसलिए है क्योंकि लक्षित ऑब्जेक्ट के नष्ट होने की संभावना हो सकती है। इसे सुरक्षित रूप से एक्सेस करने के लिए, lock() मेथड को कॉल करके अस्थायी रूप से shared_ptr प्राप्त किया जाता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


#include <iostream>
#include <memory>

class Node {
public:
 std::string name;
 std::shared_ptr<Node> next;
 std::weak_ptr<Node> prev; // सर्कुलर रेफरेंस को रोकने के लिए weak_ptr का उपयोग

 Node(const std::string& n) : name(n) { std::cout << "Created " << name << "\n"; }
 ~Node() { std::cout << "Destroyed " << name << "\n"; }
};

int main() {
 auto nodeA = std::make_shared<Node>("A");
 auto nodeB = std::make_shared<Node>("B");

 nodeA->next = nodeB;
 nodeB->prev = nodeA;

 // weak_ptr से shared_ptr प्राप्त करके एक्सेस करना
 if (auto locked_prev = nodeB->prev.lock()) {
 std::cout << "Node B's prev is " << locked_prev->name << "\n";
 } else {
 std::cout << "Node B's prev is already destroyed.\n";
 }

 return 0; // nodeA और nodeB उचित रूप से नष्ट हो जाएंगे
}

5. मल्टीथ्रेडेड वातावरण में साझा स्वामित्व की सीमाएँ

shared_ptr की थ्रेड-सुरक्षा (thread safety) के बारे में अक्सर गलतफहमी होती है। “कंट्रोल ब्लॉक में संदर्भ गणना (reference count) का अपडेट थ्रेड-सेफ होता है”, लेकिन “shared_ptr ऑब्जेक्ट को स्वयं पढ़ना या लिखना थ्रेड-सेफ नहीं होता है”।

सुरक्षित संचालन: कई थ्रेड्स, अपने स्वयं के shared_ptr इंस्टेंस (जो समान कंट्रोल ब्लॉक साझा करते हैं) को पढ़ते या लिखते हैं।
डेटा रेस (खतरा): कई थ्रेड्स, बिल्कुल एक ही shared_ptr इंस्टेंस पर एक साथ पढ़ते या लिखते हैं।

यदि एक ही इंस्टेंस को कई थ्रेड्स के बीच साझा करने की आवश्यकता है, तो std::atomic<std::shared_ptr<T>> (C++20) का उपयोग किया जाना चाहिए, या इसे म्यूटेक्स (std::mutex) के साथ सुरक्षित किया जाना चाहिए।

6. संदर्भ गणना का गणितीय सूत्रीकरण

कंट्रोल ब्लॉक में जीवनचक्र अवस्था संक्रमण (lifecycle state transition) को गणितीय रूप में निम्न प्रकार से व्यक्त किया जा सकता है: मान लें कि समय $t$ पर Strong Count $S(t)$ है और Weak Count $W(t)$ है।

प्रारंभिक अवस्था (make_shared के तुरंत बाद):

$$ S(0) = 1, \quad W(0) = 0 $$

कॉपी (shared_ptr का प्रतिरूपण) होने पर:

$$ S(t_{next}) = S(t) + 1 $$

प्रबंधित ऑब्जेक्ट (Managed Object) के नष्ट होने की स्थिति:

$$ \lim_{t \to t_d} S(t) = 0 $$

कंट्रोल ब्लॉक (Control Block) स्वयं के मेमोरी से मुक्त होने की स्थिति:

$$ S(t) = 0 \quad \land \quad W(t) = 0 $$

अर्थात,

$$ S(t) + W(t) = 0 $$

जैसा कि यह सूत्र दर्शाता है, जब तक weak_ptr मौजूद है ($W(t) > 0$), प्रबंधित ऑब्जेक्ट के नष्ट होने के बाद भी कंट्रोल ब्लॉक के लिए छोटी मेमोरी स्पेस सुरक्षित रहती है। यह make_shared का एकमात्र नुकसान हो सकता है (चूंकि प्रबंधित ऑब्जेक्ट की मेमोरी और कंट्रोल ब्लॉक एक साथ जुड़े होते हैं, यदि कोई कमजोर संदर्भ बचा रहता है, तो प्रबंधित ऑब्जेक्ट का विशाल मेमोरी स्थान भी सिस्टम को वापस नहीं किया जाता है), लेकिन आमतौर पर make_shared का प्रदर्शन लाभ इन कमियों से कहीं अधिक होता है।

7. निष्कर्ष

मॉडर्न C++ में मेमोरी प्रबंधन अब मैन्युअल रूप से new/delete को प्रबंधित करने का युग नहीं है।

डिफ़ॉल्ट रूप से हमेशा std::unique_ptr का उपयोग करें, और शून्य ओवरहेड का लाभ उठाते हुए स्पष्ट स्वामित्व को डिज़ाइन में शामिल करें।
केवल तभी std::shared_ptr का उपयोग करें जब आपको वास्तव में कई मालिकों के बीच जीवनचक्र साझा करने की आवश्यकता हो, और इसे बनाने के लिए std::make_shared का उपयोग करें।
डेटा संरचनाओं या ऑब्जर्वर पैटर्न को लागू करने में जहां साझा करने का चक्र (सर्कुलर रेफरेंस) उत्पन्न हो सकता है, वहां मेमोरी लीक को रोकने के लिए std::weak_ptr का लाभ उठाएं।

स्मार्ट पॉइंटर्स को गहराई से समझने और उनका उचित स्थान पर उपयोग करने से, C++ के प्रदर्शन से समझौता किए बिना, सुरक्षित और मजबूत सॉफ्टवेयर आर्किटेक्चर का निर्माण संभव हो जाता है。

Modern C++ on kenji.blog

C++ में मल्टीथ्रेडिंग प्रोग्रामिंग और एसिंक्रोनस प्रोसेसिंग (std::async) का परिचय

1. कंकरेंट प्रोसेसिंग की मूल बातें और एमडाहल का नियम (Amdahl’s Law)

2. थ्रेड के मूल सिद्धांत: std::thread और std::jthread (C++20)

पारंपरिक std::thread (C++11)

आधुनिक std::jthread (C++20)

3. डेटा रेस (Data Race) से बचना और सिंक्रोनाइज़ेशन: म्यूटेक्स (Mutex) और लॉक

std::mutex और std::lock_guard

std::unique_lock

4. थ्रेड्स के बीच संचार: std::condition_variable

5. उच्च-स्तरीय एसिंक्रोनस प्रोसेसिंग: std::future, std::promise, std::async

std::promise और std::future

std::async का उपयोग करके टास्क-आधारित कंकरेंट प्रोसेसिंग