Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-22 11:31:49

--- In boost_at_y..., Jeremy Siek <jsiek_at_l...> wrote:
> 
> On Thu, 22 Mar 2001 williamkempf_at_h... wrote:
> willia> I've been thinking about this, but haven't coded anything 
up yet. Let 
> willia> me ramble on about an implementation.
> willia> 
> willia> namespace boost {
> willia>   struct lock_tag { }
> willia>   struct trylock_tag { }
> willia>   struct timedlock_tag { }
> willia> 
> willia>   template <typename L>
> willia>   struct lock_traits
> willia>   {
> willia>     typedef ... lock_category;
> willia>   };
> willia> };
> 
> One thing to keep in mind... the typical purpose of such categories 
is for
> dispatching to different algorithms. However, off the top of my 
head I
> can't imagine why someone would want to do this... isn't it the 
case that
> if you need a trylock or timedlock, just a normal lock won't do?

One would assume this to be the case, yes, but I'm not 100% sure the 
assumption will always be true.  I'm feeling this suggestion out at 
this point.  I've not decided whether or not to go with this idea yet.

> willia> I can't see any other information that would go into a 
lock_traits 
> willia> type.  Is there some useful type information that I'm not 
thinking of 
> willia> that should go in here?
> willia> 
> willia> Also, one of the suggestions was to use a lock_category 
type that 
> willia> allows further decoupling of the lock types from the mutex 
types.  
> willia> Usage was like this:
> willia> 
> willia> boost::lock_category<boost::mutex>::trylock lock(mx);
> willia> 
> willia> The problem with this is that there's not a one-to-one 
correspondance 
> willia> of lock types to mutex types here.  For instance, the 
> willia> boost::fast_mutex doesn't have a trylock type.  I can think 
of a few 
> willia> ways to deal with this but was interested in hearing 
other's thoughts 
> willia> on this and wondering if there's existing practice for this 
sort of 
> willia> thing.
> 
> One way to handle this is to allow some types to be void. Another
> approach is to break the traits up.
> 
> boost::trylock<boost::mutex>::type
> boost::lock<boost::mutex>::type

This looks awful similar to boost::basic_trylock and 
boost::basic_lock.  I realize the serve drastically different 
purposes, but the names chosen here seem like they'd lead to 
confusion about the purposes of the types.

Thanks for the thoughts.

Bill Kempf