Improve SharedMemory::Lock on Posix and reenable StatsTableTest.MultipleThreads

Improve SharedMemory::Lock on Posix and reenable StatsTableTest.MultipleThreads

BUG=10611
TEST=NONE


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=123647

[jar (doing other things), 2012-02-25 00:01:39]

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory.h
File base/shared_memory.h (right):

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory.h...
base/shared_memory.h:213: // critical section using a class global lock.
Since a class-global-lock probably does not allow recursive (multiple?)
acquisitions, shouldn't the comment in line 207/208 be removed?

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory_p...
File base/shared_memory_posix.cc (right):

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory_p...
base/shared_memory_posix.cc:39: LazyInstance<Lock> g_thread_lock_ =
LAZY_INSTANCE_INITIALIZER;
Should this be a leaky lazy instance?  Are you sure that nothing bad will happen
around shutdown time??

[vandebo (ex-Chrome), 2012-02-25 01:50:36]

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory.h
File base/shared_memory.h (right):

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory.h...
base/shared_memory.h:213: // critical section using a class global lock.
On 2012/02/25 00:01:39, jar wrote:
> Since a class-global-lock probably does not allow recursive (multiple?)
> acquisitions, shouldn't the comment in line 207/208 be removed?

Done.

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory_p...
File base/shared_memory_posix.cc (right):

https://chromiumcodereview.appspot.com/9463018/diff/7001/base/shared_memory_p...
base/shared_memory_posix.cc:39: LazyInstance<Lock> g_thread_lock_ =
LAZY_INSTANCE_INITIALIZER;
On 2012/02/25 00:01:39, jar wrote:
> Should this be a leaky lazy instance?  Are you sure that nothing bad will
happen
> around shutdown time??

Good point - The existing uses *might* be ok to use with a regular LazyInstance,
but a future caller could use it in a non-safe way.  Changed to a leaky lazy
instance.

[jar (doing other things), 2012-02-25 01:52:15]

lgtm

[commit-bot: I haz the power, 2012-02-25 01:54:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vandebo@chromium.org/9463018/3004

[commit-bot: I haz the power, 2012-02-25 01:54:06]

Can't apply patch for file base/shared_memory.h.
While running patch -p1 --forward --force;
patching file base/shared_memory.h
Hunk #1 FAILED at 8.
Hunk #2 succeeded at 201 (offset 1 line).
1 out of 2 hunks FAILED -- saving rejects to file base/shared_memory.h.rej

[commit-bot: I haz the power, 2012-02-25 01:56:15]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vandebo@chromium.org/9463018/1009

[commit-bot: I haz the power, 2012-02-25 04:21:59]

Try job failure for 9463018-1009 (retry) on win_rel for step "ui_tests".
It's a second try, previously, step "ui_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2012-02-25 04:38:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vandebo@chromium.org/9463018/1009

[commit-bot: I haz the power, 2012-02-25 06:28:57]

Change committed as 123647