Re: [Threads-devel] Threading features

Subject: Re: [Threads-devel] Threading features
From: mlimber (mlimber_at_[hidden])
Date: 2009-01-08 16:18:47

On Thu, Jan 8, 2009 at 4:03 PM, Anthony Williams
<anthony_at_[hidden]> wrote:
> At Thu 08 Jan 2009 20:53:47 UTC, mlimber <mlimber_at_[hidden]> wrote:
>
>> First, I'm wondering why the UpgradeLockable concept (and hence its
>> associated locks) doesn't support timed locking like SharedLockable
>> does. And if it's not unfeasible for some reason, is there a plan to
>> add this?
>
> Timed locks are a real pain. It's probably feasible, but I don't feel the
> need to do it myself, as I wouldn't ever use it.

ISTM that it would be useful in the same places that other timed locks
are. In my case, I don't want my thread to hang up if it can't acquire
a lock, regardless of the specific type of mutex I'm locking. I want
to retry later or alert the user or whatever. Seems like a lack of
completeness to me (am I missing something?), and so I have resorted
to non-upgradable locks even though, theoretically speaking, I should
be using them.

Is the pain you speak of mainly a manpower issue (not enough time in
the day to do everything), or is there significant technical
innovation that would need to occur to make it happen, or both or
neither?

>> Second, I see that there has been some discussion of adding a
>> locking_ptr akin to Alexandrescu's code in "volatile - Multithreaded
>> Programmer's Best Friend" (http://www.ddj.com/cpp/184403766), but
>> taking into to account his semi-retractions about using volatile in
>> his non-Standard way (http://www.ddj.com/cpp/184403774) and
>> substituting a set of class templates for non-intrusive locking that
>> would correspond directly to the Boost.Thread mutex concepts -- e.g.,
>> lockable<T>, shared_lockable<T>, etc. Each *lockable<T> instance would
>> own an object of type T and would expose it through a
>> lockable<T>::locking_ptr, shared_lockable<T>::shared_locking_ptr,
>> shared_lockable<T>::unique_locking_ptr, etc. to help prevent locking
>> errors.
>>
>> I, and a goodly number of other users over the years, have
>> concurrently developed similar classes to leverage RAII and data
>> hiding in order to reduce locking errors. Seems like a good place to
>> standardize common practice. Anyone know what the status of such a
>> project is?
>
> This has been discussed several times, but I'm not aware of any plans for a
> boost submission.

Yeah, I see that it was poo-pooed previously because there were bigger
fish to fry. Is that still the case? Is there any interest in adding
such a component?

Cheers! --M