cc: Acquire worker context lock be calling BindToCurrentThread.

cc/output/output_surface.cc

Index: cc/output/output_surface.cc
diff --git a/cc/output/output_surface.cc b/cc/output/output_surface.cc
index 0786d660d4a58a3e24c03dabc3411f9d3e08cd9a..6b08e51ab836d62cfe8440f6caad5c7f3ee7bd42 100644
--- a/cc/output/output_surface.cc
+++ b/cc/output/output_surface.cc
@@ -129,6 +129,9 @@ bool OutputSurface::BindToClient(OutputSurfaceClient* client) {
   }
 
   if (success && worker_context_provider_.get()) {
+    ContextProvider::ScopedContextLock scoped_context(

[ericrk, 2015/08/24 21:00:10]

I think this may just be a naming issue and actually safe, but it seems weird
that we take the lock here before calling "SetupLock" - is SetupLock a misnomer?
comment says it "Sets up a lock so this context can be used from multiple
threads.", but it seems that it just passes the existing lock on to the command
buffer, rather than "setting up" anything.

Out of curiosity, were we hitting an issue that this fixes? if so, does that
mean there were other uses of the lock before we call "setuplock"?

[reveman, 2015/08/25 22:59:59]

Yes, the name of this function is a bit confusing. As I mentioned on the bug, we
might want to move this code out of cc::OutputSurface. Here's a patch that does
that instead:

https://codereview.chromium.org/1317743002

I think that's preferred unless there turns out to be some issues with that
approach.

+        worker_context_provider_.get());
+
     success = worker_context_provider_->BindToCurrentThread();
     if (success)
       worker_context_provider_->SetupLock();