[boost] Non-thread-safe thread library (Boost.Function)

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-12-19 07:39:45

Dear All,

In November Sergey Skorniakov wrote to this list asking about the 
non-thread-safety of Boost.Function and consequently of Boost.Thread 
itself.  Steven Watanbee replied pointing out that the problem is 
resolved in the trunk.  See:  http://thread.gmane.org/gmane.comp.lib.boost.devel/167877

My thought at the time was "chocolate teapot".  I put understanding 
this issue on my to-do list and it has finally got to the top.  
However, looking at the trac pages that Steven linked to, I am none the 
wiser; they contain patches but with no comments in the code and don't 
mention thread safety in the commit messages.

So can someone please help me understand the scope of this problem?  i.e.

- Are all uses of Boost.Function affected, or only certain uses (e.g. 
member functions vs. free functions)?

- What exactly is the race between?  E.g. if I know that I'll never 
create two threads at the same time, do I still need to worry about 
other uses of Boost.Function that may be concurrent?  Is the race 
between creating the function objects or between using them, or both?

- Can I avoid the problem by using a new version of Boost.Function, 
without upgrading other libraries?  (Is Boost.Function header-only?)

- What would the symptom of failure be?  I'm currently debugging a 
double-free somewhere below std::string::assign, which is probably unrelated.

I'm also curious to know how much more serious than this a bug would 
need to be before a Boost release would be recalled, or a new 
point-release released, or an announcement made on the Boost web page 
(which links to bugs fixed in 1.34.1, but not bugs introduced).  Surely 
there aren't many users of Boost.Thread who are happy to use a 
non-thread-safe thread library.....

Many thanks,

Phil.