Opened 13 years ago
Closed 10 years ago
#3837 closed Bugs (invalid)
thread_specific_ptr returns incorrect values if another one was constructed at the same address earlier
Reported by: | anonymous | Owned by: | viboes |
---|---|---|---|
Milestone: | Component: | thread | |
Version: | Boost 1.41.0 | Severity: | Problem |
Keywords: | tss | Cc: |
Description
optional< thread_specific_ptr<int> > optr;
void other_thread(){
optr=none;
optr=in_place();
}
int main(){
optr=in_place();
optr->reset(new int);
thread(bind(&other_thread));
this_thread::sleep(posix_time::seconds(5));
assert(optr->get() == 0); fails!
}
the assertion should not fail.
this can also be triggered by dynamic allocation. the address of thread_specific_ptr is treated as a key that is unique until the end of the thread in Boost.Thread, which is an incorrect assumption. a unique key obtained under a mutex on construction of thread_specific_ptr could be used instead.
Change History (10)
comment:1 by , 13 years ago
comment:2 by , 12 years ago
Why the assertion should not fail? You are using a global variable optr ion the two threads. The following interleaving seems possible
optr=in_place(); optr->reset(new int); main optr=none; optr=in_place(); other_thread assert(optr->get() == 0); main succeed
As the global variable has been re-assigned with in_place(). Am I missing something?
comment:3 by , 12 years ago
the assertion should not fail because the global ts-ptr has been reconstructed, so it's ptr should be 0 in each thread. but it does fail, try it.
the current ts-ptr cant handle different ts-ptrs at the same address at different points in time.
comment:4 by , 12 years ago
Status: | new → assigned |
---|
comment:5 by , 11 years ago
Keywords: | tss added |
---|
comment:6 by , 10 years ago
Milestone: | Boost 1.42.0 → To Be Determined |
---|
comment:7 by , 10 years ago
If I understand correctly, you are expecting that the destructor of the thread_specific_ptr must reset the thread specific pointer for all the threads that are using this key.
IMO, the user must ensure that the thread_specific_pointer instance outlives all the threads that are using it. Otherwise, the library needs to maintain a list of all the threads that are using a specific key, which goes against the purpose of tss to reduce the contention between threads by accessing a thread specific and not a global data.
The documentation must state clearly this constraint (design principle). Note that pthread works already in this way.
comment:8 by , 10 years ago
Milestone: | To Be Determined |
---|---|
Owner: | changed from | to
Status: | assigned → new |
comment:9 by , 10 years ago
Status: | new → assigned |
---|
comment:10 by , 10 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Doc updated accordingly. Committed in trunk at revision [80198].
More serious problems may arise if a thread_specific_ptr<X> and a thread_specific_ptr<Y> occupy the same address at different times.