Re: [boost] [thread] Exception based timed locks

20 Jan 2009


      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