scoped_lock을 잘못 사용하여 메모리 누수가 발생 했습니까?

메모리 누수가 있으며 scoped_lock (부스트)의 잘못된 사용으로 인해 발생했다고 생각됩니다. 그러나 정확한 문제를 찾아 낼 수는 없으며 코드 작성 방법도 완벽하지 않습니다.scoped_lock을 잘못 사용하여 메모리 누수가 발생 했습니까?

코드가이 클래스에 있습니다 http://taf.codeplex.com/SourceControl/changeset/view/31767#511225

주요 중요한 방법은() ThreadedLoop이다. 기본적으로이 방법은 스레드 내에서 시작되며 Yahoo에서 다운로드 할 시장 데이터를 정기적으로 확인합니다. 각 주식 (또는 기타)에 대해 새 스레드가 만들어 질 것이고 (ExecuteNextRequest() 메서드의 경우), 주식 이름이 들어있는 문자열에 대한 포인터를 매개 변수로 전달합니다. 이것은 내가 할 수있는 유일한 메모리 할당이지만 스레드 실행이 끝날 때 해제됩니다.

이 코드를 향상시킬 수있는 방법에 관심이 있습니다 (물론 스레드 풀을 사용할 수도 있지만 아직 요점은 아닙니다). 많은 감사합니다!

출처

2009-10-08 TigrouMeow

잠금 프리미티브의 오용은 메모리 누수가 아닌 교착 상태를 일으킬 수 있습니다. –

포인터 대신 간단한 std :: string을 사용할 수 있습니다. 포인터가 어떤 용도로도 사용되지는 않는다고 생각하지만, 메모리 누출의 원인이라고 생각하지 않습니다. – sth

@sth : 귀하의 의견에 동의합니다. 그러나 문자열을 변경 가능하게 사용하고이를 참조하는 모든 참조에서 변경 사항을 볼 수있는 경우에는 여전히 'shared_ptr'이 유용합니다. :-) –

std::string에 "원시"포인터를 사용하는 대신 boost::shared_ptr<std::string>을 사용하고 주위를 전달하는 것이 좋습니다. 작업이 완료되면 reset() 함수를 호출하십시오. 카운트가 0 일 때 자동으로 문자열을 비 웁니다.

보너스로 boost::weak_ptr 개체를 해당 문자열에 첨부 할 수 있습니다 (해당 문자열을 vector에 붙일 수 있음). 그들은 여전히 "살아있다". 이 방법을 사용하면 어떤 이유로 문자열이 0으로 감소하지 않는지 알 수 있습니다.

은 명확합니다 :

if (_tickersQueue.size() > 0) 
{ 
    boost::shared_ptr<std::string> ticker(new std::string(PopNextTicker())); 
    if (!ticker->empty()) 
     _threads.create_thread(boost::bind(&TAFYahooFinanceParadigm::ExecuteNextRequest, this, ticker)); 
    else 
     ticker.reset(); // optional; ticker will drop out of scope anyway 
}

예, 당신이 적절하게 ExecuteNextRequest의 기능 유형을 조정해야합니다. :-)

출처

2009-10-08 02:07:51

네, 바로 여기 원시 포인터를 사용하는 것은 쓸모가 없었습니다. 그러나 메모리 누출은 스레드의 집중적 인 생성과 관련이 있습니다 ... 최소한의 스레드 풀을 구현했으며 훨씬 더 잘 작동합니다. – TigrouMeow

scoped_lock을 잘못 사용하여 메모리 누수가 발생 했습니까?

답변

관련 문제