[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(); } Best, Vicente
----- 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? Regards, Vicente
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
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.
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Independent of the exception timeout, what do you think of a unique_lock_tuple?
It's the natural counterpart to the boost::lock() function templates. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
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?
Interesting idea. It certainly tidies up the code, which is one of my favourite features of exceptions.
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(); }
Hmm. Interesting. Have you got some realistic use cases? Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 20, 2009 3:42 PM Subject: Re: [boost] [thread] Exception based timed locks
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
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?
Interesting idea. It certainly tidies up the code, which is one of my favourite features of exceptions.
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(); }
Hmm. Interesting. Have you got some realistic use cases?
Well, the use cases are no different from the ones for the function template lock(), and a timed_lock(). I think that timed locks are used primarily for polling models and locking all the timeouts at once with a timeout guard seems natural. Unfortunately I can't give you a concrete example, but I'm sure other in this ML will find a lot of them. Could the thread library provide something like that? Thanks, Vicente
participants (4)
-
Anthony Williams -
Neil Groves -
Vicente Botet Escriba -
vicente.botet