Preparational work for an upcoming addition of a threadchecking scheme for APM

webrtc/modules/audio_processing/audio_processing_impl.h

 /*
  *  Copyright (c) 2012 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
 #ifndef WEBRTC_MODULES_AUDIO_PROCESSING_AUDIO_PROCESSING_IMPL_H_
 #define WEBRTC_MODULES_AUDIO_PROCESSING_AUDIO_PROCESSING_IMPL_H_
 
 #include <list>
 #include <string>
 #include <vector>
 
 #include "webrtc/base/scoped_ptr.h"
 #include "webrtc/base/thread_annotations.h"
+#include "webrtc/base/thread_checker.h"
 #include "webrtc/modules/audio_processing/include/audio_processing.h"
 
 namespace webrtc {
 
 class AgcManagerDirect;
 class AudioBuffer;
 class AudioConverter;
 
 template<typename T>
 class Beamformer;
@@ skipping 117 matching lines @@
   EchoControlMobileImpl* echo_control_mobile_;
   GainControlImpl* gain_control_;
   HighPassFilterImpl* high_pass_filter_;
   LevelEstimatorImpl* level_estimator_;
   NoiseSuppressionImpl* noise_suppression_;
   VoiceDetectionImpl* voice_detection_;
   rtc::scoped_ptr<GainControlForNewAgc> gain_control_for_new_agc_;
 
   std::list<ProcessingComponent*> component_list_;
   CriticalSectionWrapper* crit_;
+  rtc::ThreadChecker render_thread_checker_;

[the sun, 2015/11/11 10:50:47]

Why no rtc::ThreadChecker signal_thread_checker_; i.e., one for all the other
accesses?

[peah-webrtc, 2015/11/17 16:03:46]

I agree that these names are not that good as it is not clear what belongs to
what. Since we are mainly accessed from two threads during a call, and one is
the one handling the render data and the other is the one handling the capture
data I chose this naming scheme, but for the capture thread it is not
intuitively clear that some of the api calls should belong to that one. It may,
however, be important for the lock design that that is the case and from that
perspective I think it make sense to call the thread checker something with
"capture".

I'm not fully sure what you mean with the proposal, that the
capture_thread_checker or that the render_thread_checker should be renamed to
signal_thread_checker? 

I think any name change for the thread checkers should be reflected in a name
change for the locks in the upcoming CLs

[the sun, 2015/11/18 08:53:10]

render_... and capture_... or good names, don't worry about those.

Perhaps I'm wrong, but I though the APM was created on neither of those threads,
and that some initialization, and method calls, would also happen on non-audio
threads. If that is the case, we should have a thread checker for those as well,
and I suggested the name signal_thread_checker, because in some sense it is
signaling. 

+  rtc::ThreadChecker capture_thread_checker_;
   rtc::scoped_ptr<AudioBuffer> render_audio_;
   rtc::scoped_ptr<AudioBuffer> capture_audio_;
   rtc::scoped_ptr<AudioConverter> render_converter_;
 #ifdef WEBRTC_AUDIOPROC_DEBUG_DUMP
   // TODO(andrew): make this more graceful. Ideally we would split this stuff
   // out into a separate class with an "enabled" and "disabled" implementation.
   int WriteMessageToDebugFile();
   int WriteInitMessage();
 
   // Writes Config message. If not |forced|, only writes the current config if
@@ skipping 52 matching lines @@
   const std::vector<Point> array_geometry_;
   const SphericalPointf target_direction_;
 
   bool intelligibility_enabled_;
   rtc::scoped_ptr<IntelligibilityEnhancer> intelligibility_enhancer_;
 };
 
 }  // namespace webrtc
 
 #endif  // WEBRTC_MODULES_AUDIO_PROCESSING_AUDIO_PROCESSING_IMPL_H_