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

webrtc/modules/audio_processing/audio_processing_impl.h

Index: webrtc/modules/audio_processing/audio_processing_impl.h
diff --git a/webrtc/modules/audio_processing/audio_processing_impl.h b/webrtc/modules/audio_processing/audio_processing_impl.h
index 72dfbf419b27ee264d870c22ef5a71330ae4d7e0..68cee0607f1de7a5c44b37459c651597a2c05e2f 100644
--- a/webrtc/modules/audio_processing/audio_processing_impl.h
+++ b/webrtc/modules/audio_processing/audio_processing_impl.h
@@ -17,6 +17,7 @@
 
 #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 {
@@ -154,6 +155,8 @@ class AudioProcessingImpl : public AudioProcessing {
 
   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_;