5
Trong một trong các dự án của tôi, tôi đã xác định cuộc gọi đến std::deque<T>::clear() là một nút cổ chai lớn.Xóa STL trong chủ đề chuyên dụng
Vì vậy, tôi quyết định chuyển hoạt động này trong một chuyên dụng, chủ đề ưu tiên thấp:
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);
}
Điều này dường như làm việc tốt (VisualC++ 2010), nhưng tôi tự hỏi nếu tôi bỏ qua bất kỳ lỗ hổng lớn. Tôi sẽ hoan nghênh ý kiến của bạn về mã trên.
thông tin bổ sung:
SomeClass:clear() được gọi từ một GUI sợi, và giao diện người dùng là không đáp ứng cho đến khi trở về cuộc gọi. Mặt khác, hugeQueue không bị truy cập bởi chuỗi đó trong vài giây sau khi xóa.
Có chậm không ngay cả khi bạn chạy mà không có trình gỡ lỗi được đính kèm? –
Các hộp chứa STL không phải là chủ đề an toàn, vì vậy mã của bạn nên coi đó là tiền đề trước khi thực hiện các hoạt động trên các vùng chứa trong môi trường nhiều luồng. – DumbCoder
Có. Các deque tôi thực sự sử dụng có chứa hàng triệu đối tượng (không ints) –