Neil Groves-3 wrote:
Comments are inline...
On Tue, Jan 20, 2009 at 12:47 AM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Tuesday, January 20, 2009 1:03 AM Subject: [boost] [thread] Exception based timed locks
Hi,
I've read recently about timed locks throwing an exception when there
is a timeout.
What do you think about this behaviour? Could the thread library provide both?
Next follows a piece of code without exceptions
while (polling) { t=now()+100; boost::unique_lock<boost::mutex> l1(m1, t); if (l1.has_lock() { boost::unique_lock<boost::mutex> l2(m2, t); if (l2.has_lock() { boost::unique_lock<boost::mutex> l3(m3, t); if (l2.has_lock() { foo(); polling = false; } else execute_on_failed(); } else execute_on_failed(); } else execute_on_failed(); }
and now with exceptions
while (polling) try { t=now()+100; boost::exception_unique_lock<boost::mutex> l1(m1, t); boost::exception_unique_lock<boost::mutex> l2(m2, t); boost::exception_unique_lock<boost::mutex> l3(m3, t); foo(); polling = false; } catch (timeout_exception& ex) {execute_on_failed(); }
What do you think about a try_lock_until, try_lock_for functions
while (polling) try { boost::try_lock_for(100, m1, m2, m3); foo(); polling = false; } catch (timeout_exception& ex) {execute_on_failed(); }
Sorry, in order to be exception safe we need a kind of scoped lock for tuples
while (polling) try { exception_unique_lock_tuple<mutex, shared_mutex, mutex>(100, m1, m2, m3); foo(); polling = false; } catch (timeout_exception& ex) {execute_on_failed(); }
Independent of the exception timeout, what do you think of a unique_lock_tuple?
The example is compelling. I would like to see no-throw alternatives in addition to the functions you have described. The unique_lock_tuple appears to be nice syntactic sugar, but I very rarely need to grab multiple locks so it's not a must-have feature for me.
Regards, Vicente
Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thanks. Excelent idea with no_throw we could have template <typename DurationType, typename M1, ... Mk) try_lock_for(DurationType d, M1 m1, Mk mk); which can throw timeout_exception and template <typename DurationType, typename M1, ... Mk) try_lock_for(no_throw_t,DurationType d, M1 m1, Mk mk); It is a shaem that we can not overload the unique_lock constructor as the current behavior do not corresponds to the no_throw (no default semantics) and will break a lot of code. Maybe we can add a throw_on_timeout tag. Respect to the unique_lock_tuple it is the application of the exception safe application of the RAII idiom of lock(m1, m2,... mk)/unlock(m1, m2,..., mk) as unique_lock(m) is for m.lock()/m.unlock(). Both multi lock and unlock are already on the library, so we need the corresponding unique_lock. As this is a new class the no_throw trick can be used. Best, Vicente -- View this message in context: http://www.nabble.com/-thread--Exception-based-timed-locks-tp21554444p215616... Sent from the Boost - Dev mailing list archive at Nabble.com.