6
मैं एक साधारण पूल ऑब्जेक्ट बनाने की कोशिश कर रहा हूं, जिसे मैं साझा संसाधनों के एक सेट तक पहुंचने के लिए पर्याप्त रूप से कम से कम आवंटित करना चाहता हूं जो इसके लिए पूछता है। विंडोज़ में, मेरे पास आमतौर पर म्यूटेक्स की एक सरणी होती है और bWaitAll = FALSE के साथ एक WaitForMultipleObjects करता है (नीचे windows_pool_of_n_t देखें)। लेकिन मुझे उम्मीद है कि किसी दिन इसे अन्य ओएस में पोर्ट करने में सक्षम हो, इसलिए मैं मानक के साथ रहना चाहता हूं। संसाधनों का एक डेक, एक शर्त के साथ आकार()! = 0 स्पष्ट समाधान की तरह लग रहा था (नीचे pool_of_n_t देखें)।std :: condition_variable शेड्यूलिंग को अनुचित क्यों करता है?
लेकिन कारणों से मुझे समझ में नहीं आता है, वह कोड थ्रेड पहुंच को क्रमबद्ध करता है। मुझे सख्त निष्पक्षता की उम्मीद नहीं है, लेकिन यह सबसे खराब संभव मामला है - पिछली बार लॉक था जो थ्रेड था अगली बार लॉक हमेशा मिलता है। ऐसा नहीं है कि std :: mutex विंडोज़ कम या कम निष्पक्ष शेड्यूलिंग के अनुरूप नहीं है, क्योंकि कंडीशन वैरिएबल कार्यों के बिना केवल एक म्यूटेक्स का उपयोग करने के बाद, हालांकि केवल एक के पूल के लिए (नीचे पूल_of_one_t देखें)।
क्या कोई इसे समझा सकता है? क्या इसके चारों ओर एक रास्ता है?
परिणाम:
C:\temp\stdpool>bin\stdpool.exe
pool:pool_of_one_t
thread 0:19826 ms
thread 1:19846 ms
thread 2:19866 ms
thread 3:19886 ms
thread 4:19906 ms
thread 5:19926 ms
thread 6:19946 ms
thread 7:19965 ms
thread 8:19985 ms
thread 9:20004 ms
pool:windows_pool_of_n_t(1)
thread 0:19819 ms
thread 1:19838 ms
thread 2:19858 ms
thread 3:19878 ms
thread 4:19898 ms
thread 5:19918 ms
thread 6:19938 ms
thread 7:19958 ms
thread 8:19978 ms
thread 9:19997 ms
pool:pool_of_n_t(1)
thread 9:3637 ms
thread 0:4538 ms
thread 6:7558 ms
thread 4:9779 ms
thread 8:9997 ms
thread 2:13058 ms
thread 1:13997 ms
thread 3:17076 ms
thread 5:17995 ms
thread 7:19994 ms
pool:windows_pool_of_n_t(2)
thread 1:9919 ms
thread 0:9919 ms
thread 2:9939 ms
thread 3:9939 ms
thread 5:9958 ms
thread 4:9959 ms
thread 6:9978 ms
thread 7:9978 ms
thread 9:9997 ms
thread 8:9997 ms
pool:pool_of_n_t(2)
thread 2:6019 ms
thread 0:7882 ms
thread 4:8102 ms
thread 5:8182 ms
thread 1:8382 ms
thread 8:8742 ms
thread 7:9162 ms
thread 9:9641 ms
thread 3:9802 ms
thread 6:10201 ms
pool:windows_pool_of_n_t(5)
thread 4:3978 ms
thread 3:3978 ms
thread 2:3979 ms
thread 0:3980 ms
thread 1:3980 ms
thread 9:3997 ms
thread 7:3999 ms
thread 6:3999 ms
thread 5:4000 ms
thread 8:4001 ms
pool:pool_of_n_t(5)
thread 2:3080 ms
thread 0:3498 ms
thread 8:3697 ms
thread 3:3699 ms
thread 6:3797 ms
thread 7:3857 ms
thread 1:3978 ms
thread 4:4039 ms
thread 9:4057 ms
thread 5:4059 ms
कोड:
#include <iostream>
#include <deque>
#include <vector>
#include <mutex>
#include <thread>
#include <sstream>
#include <chrono>
#include <iomanip>
#include <cassert>
#include <condition_variable>
#include <windows.h>
using namespace std;
class pool_t {
public:
virtual void check_in(int size) = 0;
virtual int check_out() = 0;
virtual string pool_name() = 0;
};
class pool_of_one_t : public pool_t {
mutex lock;
public:
virtual void check_in(int resource) {
lock.unlock();
}
virtual int check_out() {
lock.lock();
return 0;
}
virtual string pool_name() {
return "pool_of_one_t";
}
};
class windows_pool_of_n_t : public pool_t {
vector<HANDLE> resources;
public:
windows_pool_of_n_t(int size) {
for (int i=0; i < size; ++i)
resources.push_back(CreateMutex(NULL, FALSE, NULL));
}
~windows_pool_of_n_t() {
for (auto resource : resources)
CloseHandle(resource);
}
virtual void check_in(int resource) {
ReleaseMutex(resources[resource]);
}
virtual int check_out() {
DWORD result = WaitForMultipleObjects(resources.size(),
resources.data(), FALSE, INFINITE);
assert(result >= WAIT_OBJECT_0
&& result < WAIT_OBJECT_0+resources.size());
return result - WAIT_OBJECT_0;
}
virtual string pool_name() {
ostringstream name;
name << "windows_pool_of_n_t(" << resources.size() << ")";
return name.str();
}
};
class pool_of_n_t : public pool_t {
deque<int> resources;
mutex lock;
condition_variable not_empty;
public:
pool_of_n_t(int size) {
for (int i=0; i < size; ++i)
check_in(i);
}
virtual void check_in(int resource) {
unique_lock<mutex> resources_guard(lock);
resources.push_back(resource);
resources_guard.unlock();
not_empty.notify_one();
}
virtual int check_out() {
unique_lock<mutex> resources_guard(lock);
not_empty.wait(resources_guard,
[this](){return resources.size() > 0;});
auto resource = resources.front();
resources.pop_front();
bool notify_others = resources.size() > 0;
resources_guard.unlock();
if (notify_others)
not_empty.notify_one();
return resource;
}
virtual string pool_name() {
ostringstream name;
name << "pool_of_n_t(" << resources.size() << ")";
return name.str();
}
};
void worker_thread(int id, pool_t& resource_pool)
{
auto start_time = chrono::system_clock::now();
for (int i=0; i < 100; ++i) {
auto resource = resource_pool.check_out();
this_thread::sleep_for(chrono::milliseconds(20));
resource_pool.check_in(resource);
this_thread::yield();
}
static mutex cout_lock;
{
unique_lock<mutex> cout_guard(cout_lock);
cout << "thread " << id << ":"
<< chrono::duration_cast<chrono::milliseconds>(
chrono::system_clock::now() - start_time).count()
<< " ms" << endl;
}
}
void test_it(pool_t& resource_pool)
{
cout << "pool:" << resource_pool.pool_name() << endl;
vector<thread> threads;
for (int i=0; i < 10; ++i)
threads.push_back(thread(worker_thread, i, ref(resource_pool)));
for (auto& thread : threads)
thread.join();
}
int main(int argc, char* argv[])
{
test_it(pool_of_one_t());
test_it(windows_pool_of_n_t(1));
test_it(pool_of_n_t(1));
test_it(windows_pool_of_n_t(2));
test_it(pool_of_n_t(2));
test_it(windows_pool_of_n_t(5));
test_it(pool_of_n_t(5));
return 0;
}
यह एक कठिन सवाल हो सकता है। मेरा मतलब है, आसान जवाब है: 'condition_variable' ऐसी कोई गारंटी नहीं देता है। कठिन जवाब यह बता रहा है कि यह कितना बुरा है, मानते हुए कि आपने अपने उपरोक्त कोड में स्पष्ट ओप्स नहीं बनाया है। – Yakk
मुझे कोई स्पष्ट ओह नहीं दिख रहा है। मुझे संदेह है कि यह 'this_thread :: उपज()' और दो अलग-अलग म्यूटेक्स मार्गों के बीच थोड़ा अलग इंटरैक्शन के कारण है। लिनक्स में, मुझे उम्मीद है कि आपका कोड काफी हद तक शेड्यूल करेगा। ध्यान दें कि मानक 'उपज' के रूप में * केवल पुन: निर्धारित करने का अवसर * के रूप में बोलता है लेकिन विवरण ओएस-विशिष्ट हैं। यह 'this_thread :: उपज();' '___read :: sleep_for (chrono :: nanoseconds (1)) के साथ' this_thread :: उपज(); 'को बदलने का प्रयास करने के लिए एक प्रयोग के रूप में दिलचस्प हो सकता है; यह शेड्यूलिंग कतार में थ्रेड के प्राथमिकता के नुकसान को मजबूर करेगा और शायद विंडोज़ में मतभेदों को खत्म करेगा। –
न तो sleep_for() और न ही Win32 की :: नींद() परिणाम बेहतर शेड्यूलिंग में। ऐसा लगता है जैसे याक की टिप्पणी जवाब है - मानक इसका वादा नहीं करता है और मुझे इस पर भरोसा करने की कोशिश नहीं करनी चाहिए। –