That's interesting. Is it really necessary to have a release_guard that re-locks in the destructor? What's the point? I could read the spec, but I'll ask instead: Isn't the compiler allowed to optimize away some scoping? Is it required that objects be destructed in the order they were constructed (if they're in the same stack frame)? If an exception is thrown while the release_guard is in scope, is it guaranteed that the release_guard will be destructed before the guard? Bad things will happen if it's done out-of-order. I thought I understood most of these issues, but reading your stuff on this list makes me feel like a newbie. Thanks, - Mark Alexander Terekhov wrote:
"William E. Kempf" wrote: [...]
means short blocks, even if artificial. Short code blocks combined with the need to carefully analyze synchronization leads to little chance of making the mistake you illustrate.
But explicit unlocking (also "RAII" based) sometimes IS "needed".
http://terekhov.de/DESIGN-futex-CV.cpp
~futex_condvar() { mutex::guard guard( m_mutex ); assert( m_waiters[0] == m_wakeups ); while ( m_waiters[0] ) { int ftx = m_futex = EOC(); mutex::release_guard release_guard( guard ); cancel_off_guard no_cancel; m_futex.wait( ftx ); } }
regards, alexander.
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/