thread_specific_ptr multithread confusion - c++

Question

// code snippet 1
static boost::thread_specific_ptr<StreamX> StreamThreadSpecificPtr;
void thread_proc() {
StreamX * stream = NULL;
stream = StreamThreadSpecificPtr.get();
if (NULL == stream) {
stream = new StreamX();
StreamThreadSpecificPtr.reset(stream);
}
printf("%p\n", stream);
}
int run() {
boost::thread_group threads;
for(int i = 0; i < 5; i ++) {
threads.create_thread(&thread_proc);
}
threads.join_all();
}
// the result is
0x50d560 -- SAME POINTER
0x50d540
0x50bfc0
0x50bef0
0x50d560 -- SAME POINTER
// code snippet 2
static boost::thread_specific_ptr<StreamX> StreamThreadSpecificPtr(NULL); // DIFF from code snippet 1
void thread_proc() {
StreamX * stream = NULL;
stream = StreamThreadSpecificPtr.get();
if (NULL == stream) {
stream = new StreamX();
StreamThreadSpecificPtr.reset(stream);
}
printf("%p\n", stream);
}
int run() {
boost::thread_group threads;
for(int i = 0; i < 5; i ++) {
threads.create_thread(&thread_proc);
}
threads.join_all();
}
// the result is
0x50d510
0x50d4f0
0x50bf70
0x50ca70
0x50be50
In code snippet 1, two pointer are same. it is not expected.
In code snippet 2, with initializing StreamThreadSpecificPtr to NULL, everything seams good.
Could you please help to figure out the answer for this confusion? Thanks a lot.

Answer 1

The joy is that your threads are actually terminating asynchronously, destructing the StreamX instances.
Using a detector:
struct StreamX
{
StreamX() { puts(__FUNCTION__); }
~StreamX() { puts(__FUNCTION__); }
};
I get the following output:
StreamX
0x7f258c0008c0
~StreamX
StreamX
0x7f25740008c0
~StreamX
StreamX
0x7f25840008c0
~StreamX
StreamX
0x7f25780008c0
StreamX
~StreamX
0x7f257c0008c0
~StreamX
real 0m0.002s
user 0m0.000s
sys 0m0.004s
It makes sense for subsequent allocations to reuse the same heap addresses, since there isn't much fragmentation involved. In other words, you can't just compare pointers to see whether they alias the same object in a concurrent application.
The difference with the second example is only spurious. There are many factors that can - and will - influence the result. E.g. adding a tiny delay at the end of each thread will remove all opportunity for threads to terminate before other instances have been instantiated.
See it Live On Coliru