Make it possible to have 1 PpapiGlobals per thread. Update unit tests.

ppapi/shared_impl/proxy_lock.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ppapi/shared_impl/proxy_lock.h"
 
 #include "base/synchronization/lock.h"
+#include "ppapi/shared_impl/ppapi_globals.h"
 
 namespace ppapi {
 
 base::Lock* ProxyLock::lock_ = NULL;
 
 // static
 void ProxyLock::Acquire() {
-  if (lock_)
-    lock_->Acquire();
+  base::Lock* lock(PpapiGlobals::Get()->GetProxyLock());

[brettw, 2012/01/05 23:41:20]

Is this class useful anymore? I probably just would put Acquire and Release on
the globals object. 

[dmichael (off chromium), 2012/01/06 18:18:45]

I agree, that would be nicer for right now, and I almost did it. But I think
we're going to need access to the naked lock later when we implement blocking
completion callbacks (presumably using condition variables). So I'm leaning
towards leaving just the GetProxyLock there and these convenience classes here.
If you don't want me to leave this "speculative" design choice in, though, just
let me know. Your suggestion is definitely cleaner in the short term.

+  if (lock)
+    lock->Acquire();
 }
 
 // static
 void ProxyLock::Release() {
-  if (lock_)
-    lock_->Release();
-}
-
-// static
-void ProxyLock::Set(base::Lock* lock) {
-  lock_ = lock;
-}
-
-// static
-void ProxyLock::Reset() {
-  Set(NULL);
+  base::Lock* lock(PpapiGlobals::Get()->GetProxyLock());
+  if (lock)
+    lock->Release();
 }
 
 }  // namespace ppapi