Index: base/threading/thread_local_storage_win.cc |
=================================================================== |
--- base/threading/thread_local_storage_win.cc (revision 111452) |
+++ base/threading/thread_local_storage_win.cc (working copy) |
@@ -29,8 +29,8 @@ |
// An array of destructor function pointers for the slots. If |
// a slot has a destructor, it will be stored in its corresponding |
// entry in this array. |
-ThreadLocalStorage::TLSDestructorFunc |
- ThreadLocalStorage::tls_destructors_[kThreadLocalStorageSize]; |
+subtle::AtomicWord |
+ ThreadLocalStorage::tls_destructors_[kThreadLocalStorageSize]; |
void** ThreadLocalStorage::Initialize() { |
if (tls_key_ == TLS_OUT_OF_INDEXES) { |
@@ -49,9 +49,22 @@ |
} |
DCHECK(!TlsGetValue(tls_key_)); |
- // Create an array to store our data. |
+ // Some allocators, such as TCMalloc, make use of thread local storage. |
+ // As a result, any attempt to call new (or malloc) will lazilly cause such a |
willchan no longer on Chromium
2011/11/29 01:46:49
s/lazilly/lazily/g
jar (doing other things)
2011/11/29 02:32:45
Done.
|
+ // system to initialize, which will include registering for a TLS key. If we |
+ // are not careful here, then that request to create a key will call new back, |
+ // and we'll have an infinite loop. We avoid that as follows: |
+ // Use use a stack allocated vector, so that we don't have dependence |
willchan no longer on Chromium
2011/11/29 01:46:49
s/Use use/Use/g
jar (doing other things)
2011/11/29 02:32:45
Done.
|
+ // on our allocator until our service is in place. (i.e., don't |
+ // even call new until after we're setup) |
+ void* stack_allocated_tls_data[kThreadLocalStorageSize]; |
+ memset(stack_allocated_tls_data, 0, sizeof(stack_allocated_tls_data)); |
willchan no longer on Chromium
2011/11/29 01:46:49
s/sizeof/arraysize/
jar (doing other things)
2011/11/29 02:32:45
I think I want the size of the array. Array size
|
+ // Ensure that any rentrant calls change the temp version. |
willchan no longer on Chromium
2011/11/29 01:46:49
re-entrant
jar (doing other things)
2011/11/29 02:32:45
Done.
|
+ TlsSetValue(tls_key_, stack_allocated_tls_data); |
+ |
+ // Allocate an array to store our data. |
void** tls_data = new void*[kThreadLocalStorageSize]; |
- memset(tls_data, 0, sizeof(void*[kThreadLocalStorageSize])); |
+ memcpy(tls_data, stack_allocated_tls_data, sizeof(stack_allocated_tls_data)); |
willchan no longer on Chromium
2011/11/29 01:46:49
s/sizeof/arraysize/
jar (doing other things)
2011/11/29 02:32:45
Again... I think I have the right form.
willchan no longer on Chromium
2011/11/29 02:47:04
Oops, you're right. Ignore me.
|
TlsSetValue(tls_key_, tls_data); |
return tls_data; |
} |
@@ -68,13 +81,16 @@ |
// Grab a new slot. |
slot_ = InterlockedIncrement(&tls_max_) - 1; |
+ DCHECK_GT(slot_, 0); |
if (slot_ >= kThreadLocalStorageSize) { |
NOTREACHED(); |
return false; |
} |
- // Setup our destructor. |
- tls_destructors_[slot_] = destructor; |
+ // Setup our destructor. Make sure that any thread that is dostroyed can see |
rvargas (doing something else)
2011/11/29 01:26:31
nit: typo
jar (doing other things)
2011/11/29 02:32:45
Done.
|
+ // this new setting. |
+ subtle::NoBarrier_Store(&tls_destructors_[slot_], |
rvargas (doing something else)
2011/11/29 01:26:31
Isn't it more readable to do a regular assignment?
jar (doing other things)
2011/11/29 02:32:45
Yeah... but I think it is a bit wrong. Perhaps if
rvargas (doing something else)
2011/11/29 02:46:46
The way I'm reading this code (I may be wrong) is
|
+ reinterpret_cast<subtle::AtomicWord>(destructor)); |
initialized_ = true; |
return true; |
} |
@@ -82,7 +98,10 @@ |
void ThreadLocalStorage::Slot::Free() { |
// At this time, we don't reclaim old indices for TLS slots. |
// So all we need to do is wipe the destructor. |
- tls_destructors_[slot_] = NULL; |
+ DCHECK_GT(slot_, 0); |
+ DCHECK_LT(slot_, kThreadLocalStorageSize); |
+ subtle::NoBarrier_Store(&tls_destructors_[slot_], NULL); |
+ slot_ = 0; |
initialized_ = false; |
} |
@@ -90,7 +109,7 @@ |
void** tls_data = static_cast<void**>(TlsGetValue(tls_key_)); |
if (!tls_data) |
tls_data = ThreadLocalStorage::Initialize(); |
- DCHECK_GE(slot_, 0); |
+ DCHECK_GT(slot_, 0); |
DCHECK_LT(slot_, kThreadLocalStorageSize); |
return tls_data[slot_]; |
} |
@@ -99,7 +118,7 @@ |
void** tls_data = static_cast<void**>(TlsGetValue(tls_key_)); |
if (!tls_data) |
tls_data = ThreadLocalStorage::Initialize(); |
- DCHECK_GE(slot_, 0); |
+ DCHECK_GT(slot_, 0); |
DCHECK_LT(slot_, kThreadLocalStorageSize); |
tls_data[slot_] = value; |
} |
@@ -109,21 +128,56 @@ |
return; |
void** tls_data = static_cast<void**>(TlsGetValue(tls_key_)); |
- |
// Maybe we have never initialized TLS for this thread. |
if (!tls_data) |
return; |
- for (int slot = 0; slot < tls_max_; slot++) { |
- if (tls_destructors_[slot] != NULL) { |
- void* value = tls_data[slot]; |
- tls_destructors_[slot](value); |
+ // Some allocators, such as TCMalloc, use TLS. As a result, when a thread |
+ // terminates, one of the destructor calls we make may be to shut down an |
+ // allocator. We have to be careful that after we've shutdown all of the |
+ // known destructors (perchance including an allocator), that we don't call |
+ // the allocator and cause it to resurrect itself (with no possibly destructor |
+ // call to follow). We handle this problem as follows: |
+ // Switch to using a stack allocated vector, so that we don't have dependence |
+ // on our allocator after we have called all tls_destructors_. (i.e., don't |
+ // even call delete[] after we're done with destructors.) |
+ void* stack_allocated_tls_data[kThreadLocalStorageSize]; |
+ memcpy(stack_allocated_tls_data, tls_data, sizeof(stack_allocated_tls_data)); |
+ // Ensure that any rentrant calls change the temp version. |
+ TlsSetValue(tls_key_, stack_allocated_tls_data); |
+ delete[] tls_data; // Our last dependence on an allocator. |
+ |
+ int remaining_attempts = PTHREAD_DESTRUCTOR_ITERATIONS; |
+ bool need_to_scan_destructors = true; |
+ while (need_to_scan_destructors) { |
+ need_to_scan_destructors = false; |
+ // Try to destroy the first-created-slot (which is slot 1) in our last |
+ // destructor call. That user was able to function, and define a slot with |
+ // no other services running, so perhaps it is a basic service (like an |
+ // allocator) and should also be destroyed last. |
+ for (int slot = tls_max_ - 1; slot > 0; --slot) { |
+ void* value = stack_allocated_tls_data[slot]; |
+ if (value == NULL) |
+ continue; |
+ TLSDestructorFunc destructor = |
+ reinterpret_cast<ThreadLocalStorage::TLSDestructorFunc>( |
+ subtle::NoBarrier_Load(&tls_destructors_[slot])); |
+ if (destructor == NULL) |
+ continue; |
+ stack_allocated_tls_data[slot] = NULL; // pre-clear the slot. |
+ destructor(value); |
+ // Any destructor might have called a different service, which then set |
+ // a different slot to a non-NULL value. Hence we need to check |
+ // the whole vector again. This is a pthread standard. |
+ need_to_scan_destructors = true; |
} |
+ if (--remaining_attempts <= 0) { |
+ NOTREACHED(); // Destructors might not have been called. |
+ break; |
+ } |
} |
- delete[] tls_data; |
- |
- // In case there are other "onexit" handlers... |
+ // Remove our stack allocated vector. |
TlsSetValue(tls_key_, NULL); |
} |