Fix race between ~SkThreadPool and SkThreadPool::Loop on fDone.

We're writing fDone without holding the mutex.  Bad form, says tsan.

In practice this is fairly innocuous, as fDone only ever goes from false to
true and only once.  Though, I wouldn't be surprised if there were some way
this could leak a thread that never got the signal to die.

BUG=
R=scroggo@google.com, reed@google.com

Author: mtklein@google.com

Review URL: https://codereview.chromium.org/25371003

git-svn-id: http://skia.googlecode.com/svn/trunk@11563 2bbb7eff-a529-9590-31e7-b0007b416f81

1 files changed, 1 insertions, 1 deletions

diff --git a/src/utils/SkThreadPool.cpp b/src/utils/SkThreadPool.cpp
index 5fe10255b5..3d19d1c5b9 100644
--- a/src/utils/SkThreadPool.cpp
+++ b/src/utils/SkThreadPool.cpp
@@ -39,8 +39,8 @@ SkThreadPool::SkThreadPool(int count)
 }
 
 SkThreadPool::~SkThreadPool() {
-    fDone = true;
     fReady.lock();
+    fDone = true;
     fReady.broadcast();
     fReady.unlock();