Boost logo

Boost :

Subject: Re: [boost] [thread] Exception based timed locks
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2009-01-20 06:47:21


Neil Groves-3 wrote:
>
> 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://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-tp21554444p21561621.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk