Potential dead lock in receive statistics

A dead lock could occur if the following to code paths are called
concurrently:

ReceiveStatisticsImpl::IncomingPacket() ->
  StreamStatisticianImpl::IncomingPacket()

StreamStatisticianImpl::GetStatistics() ->
  ReceiveStatisticsImpl::StatisticsUpdated()

Solution is to release ReceiveStatisticsImpl lock after lookup/lazy-init of StreamStatisticianImpl. Don't need to hold it when doing the call to StreamStatisticianImpl::IncomingPacket().

BUG=2818
R=asapersson@webrtc.org, stefan@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/7389004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5406 4adac7df-926f-26a2-2b94-8c16560cd09d
This commit is contained in:
sprang@webrtc.org
2014-01-21 16:33:37 +00:00
parent 32c3247418
commit 7dba27c740
2 changed files with 69 additions and 56 deletions

View File

@ -45,9 +45,10 @@ class StreamStatisticianImpl : public StreamStatistician {
private:
bool InOrderPacketInternal(uint16_t sequence_number) const;
RtcpStatistics CalculateStatistics();
Clock* clock_;
scoped_ptr<CriticalSectionWrapper> crit_sect_;
scoped_ptr<CriticalSectionWrapper> stream_lock_;
Bitrate incoming_bitrate_;
uint32_t ssrc_;
int max_reordering_threshold_; // In number of packets or sequence numbers.
@ -112,7 +113,7 @@ class ReceiveStatisticsImpl : public ReceiveStatistics,
typedef std::map<uint32_t, StreamStatisticianImpl*> StatisticianImplMap;
Clock* clock_;
scoped_ptr<CriticalSectionWrapper> crit_sect_;
scoped_ptr<CriticalSectionWrapper> receive_statistics_lock_;
int64_t last_rate_update_ms_;
StatisticianImplMap statisticians_;