Boost logo

Boost :

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
> > reading, I've uploaded the following:
> >
> >
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at