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 anonymous, 13 years ago

More serious problems may arise if a thread_specific_ptr<X> and a thread_specific_ptr<Y> occupy the same address at different times.

comment:2 by anonymous, 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 anonymous, 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 Anthony Williams, 12 years ago

Status: newassigned

comment:5 by viboes, 11 years ago

Keywords: tss added

comment:6 by viboes, 10 years ago

Milestone: Boost 1.42.0To Be Determined

comment:7 by viboes, 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.

Last edited 10 years ago by viboes (previous) (diff)

comment:8 by viboes, 10 years ago

Milestone: To Be Determined
Owner: changed from Anthony Williams to viboes
Status: assignednew

comment:9 by viboes, 10 years ago

Status: newassigned

comment:10 by viboes, 10 years ago

Resolution: invalid
Status: assignedclosed

Doc updated accordingly. Committed in trunk at revision [80198].

Note: See TracTickets for help on using tickets.