Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-07 13:03:04

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> 
> > If you click on just the right sequence, and your machine is set 
up just
> > right, and blah blah blah you can actually see the files rendered
> > correctly. But to make it easier to get the whole package for 
local
> > reading, I've uploaded the following:
> >
> > 
http://groups.yahoo.com/group/boost/files/threads/thread_doc_snapshot.
zip
> 
> faq.html:
> 
> >>   // For assignment we need to synchronize both objects!
> >>   const counter& operator=(const counter& other)
> >>   {
> >>      boost::mutex::scoped_lock scoped_lock(m_mutex);
> >>      boost::mutex::scoped_lock scoped_lock(other.m_mutex);
> >>      m_value = other.m_value;
> >>      return *this;
> >>   }
> 
> is rather dangerous; potential deadlock for

Agreed, but this code exists just to illustrate a point, not as an 
example of safe/robust code.  The "fixes" to this synchronization 
problem just make the example harder to read.  I'd rather just add a 
comment explaining that the code isn't really safe as written but is 
intended to illustrate the issue.  Thoughts on this?

> <still hating _lock name/lack of "cleanup handler" semantics>

Arguing the name is pointless at this point, so let's drop that one.  
Could you explain again what you mean by "cleanup handler" semantics 
and why traditional C++ cleanup semantics won't suffice?

Bill Kempf