Subject: Re: [boost] [thread] Exception based timed locks
From: Neil Groves (neil_at_[hidden])
Date: 2009-01-20 03:28:57
Comments are inline...
On Tue, Jan 20, 2009 at 12:47 AM, vicente.botet <vicente.botet_at_[hidden]>wrote:
> ----- Original Message -----
> From: "vicente.botet" <vicente.botet_at_[hidden]>
> To: <boost_at_[hidden]>
> 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://listarchives.boost.org/mailman/listinfo.cgi/boost
>