5
मेरी परियोजनाओं में से एक में, मैंने एक बड़ी बाधा के रूप में std::deque<T>::clear() पर एक कॉल की पहचान की।समर्पित धागे में एसटीएल साफ़ करना
इसलिए मैं एक समर्पित, कम प्राथमिकता सूत्र में इस कार्रवाई को ले जाने का फैसला किया:
template <class T>
void SomeClass::parallelClear(T& c)
{
if (!c.empty())
{
T* temp = new T;
c.swap(*temp); // swap contents (fast)
// deallocate on separate thread
boost::thread deleteThread([=]() { delete temp; });
// Windows specific: lower priority class
SetPriorityClass(deleteThread.native_handle(), BELOW_NORMAL_PRIORITY_CLASS);
}
}
void SomeClass:clear(std::deque<ComplexObject>& hugeDeque)
{
parallelClear(hugeDeque);
}
यह (VisualC++ 2010) ठीक से काम करने लगता है, लेकिन मुझे आश्चर्य है कि अगर मैं किसी भी प्रमुख दोष अनदेखी की। मैं उपरोक्त कोड के बारे में आपकी टिप्पणियों का स्वागत करता हूं।
अतिरिक्त जानकारी:
SomeClass:clear() एक जीयूआई-धागे से कहा जाता है, और यूजर इंटरफेस कॉल रिटर्न जब तक उत्तर नहीं देता है। दूसरी तरफ, hugeQueue, समाशोधन के बाद कई सेकंड के लिए उस धागे द्वारा उपयोग की जाने वाली संभावना नहीं है।
क्या यह धीमा है भले ही आप डीबगर संलग्न किए बिना चलाए? –
एसटीएल कंटेनर स्वयं थ्रेड सुरक्षित नहीं हैं, इसलिए आपके कोड को एक बहु थ्रेडेड वातावरण में कंटेनर पर संचालन करने से पहले इसे आधार के रूप में लेना चाहिए। – DumbCoder
हां। वास्तव में उपयोग किए जाने वाले डेक में लाखों ऑब्जेक्ट्स (इनट्स नहीं) –