Subject: Re: [boost] [thread] thread_specific_ptr, dangerous conflation of identity and address
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2010-02-16 03:44:58
"vicente.botet" <vicente.botet_at_[hidden]> writes:
> ----- Original Message -----
> From: <strasser_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, February 15, 2010 11:54 PM
> Subject: Re: [boost] [thread] thread_specific_ptr, dangerous conflation of identity and address
>> Zitat von Edd Dawson <lists_at_[hidden]>:
>>> The bigger problem though, is that it might not be *their* old data.
>>> It can just as easily be someone else's old data due to coincidental
>>> alignment of different thread_specific_ptrs on the stack at entirely
>>> unrelated points in the program, or even in different libraries that
>>> each happen to use boost::thread_specific_ptr!
>>> It's easy to see the problem here as the calls are very close to one
>>> another. In general, however, this strikes me as being really rather
>>> dangerous behaviour.
>>> Would it be fair to call it a bug?
> I find this a rather severe design bug. I will propose you to change
> the severity to showstopper as we can not use thread_specific_ptr
> other than statically. Anthony, what do you think?
I think that using a thread_specific_ptr as an automatic variable is
incorrect usage. The lifetime of the variable is strictly limited to the
duration of the function call, and each thread that calls the function
will get its own copy of the thread_specific_ptr. Under such
circumstances you really ought to just use a plain ordinary variable.
It is primarily intended for use with static storage
duration. Unfortunately I haven't had a chance to look at the proposed
changes. I'll try and get to it today.
-- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk