Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-22 15:16:44

--- In boost_at_y..., "Mark Rodgers" <mark.rodgers_at_c...> wrote:
> > > The only suggestion left to 
> > > contemplate at this time is the addition of a lock traits 
concept.
> > 
> > I've been thinking about this, but haven't coded anything up yet. 
Let 
> > me ramble on about an implementation.
> > 
> > namespace boost {
> >   struct lock_tag { }
> >   struct trylock_tag { }
> >   struct timedlock_tag { }
> > 
> >   template <typename L>
> >   struct lock_traits
> >   {
> >     typedef ... lock_category;
> >   };
> > };
> > 
> > I can't see any other information that would go into a 
lock_traits 
> > type.  Is there some useful type information that I'm not 
thinking of 
> > that should go in here?
> 
> I think there are two things that you might need to know:
> 
> 1.  Given a mutex, what sort of locks does it support?
> 2.  Given a lock, what sort is it?
> 
> I can see (1) being useful when for example, you are implementing
> some sort of threadsafe class, and you want to allow users to 
specify
> the mutex type as a policy.  Your implementation might vary based on
> what type of locks you consequently have available.
> 
> I think (2) is a bit more tenuous, but easy to implement so I see
> no reason not to provide it.
> 
> Perhaps we need numeric_limits-like functionality either instead 
> of categories, or as well them:
> 
> template <class Lock> struct lock_traits {};
> 
> template <T> struct lock_traits< basic_lock<T> >
> {
>   static const bool is_timed = false;
>   static const bool is_try = false;
>   static const bool is_interprocess = false;
> };
> 
> I don't know.  I think this is where we need to really gain some 
> experience before we make a decision.  

Definately, though thinking about this now is still beneficial.

> Perhaps if we added a threading policy to shared_ptr, we'd get a 
better 
> idea.  That also means we might want a dummy null_mutex class that 
looks 
> like a mutex but does nothing, for use in single-threaded 
environments.

Shared pointer might be able to be made thread safe with out the need 
for locks.  So I'm not sure this is a good candidate for "getting a 
better idea".  I agree about the null_mutex, it just didn't deserve 
full attention up front.  Implementation would be more than trivial, 
after all, and it's presence won't help with evaluating the 
interfaces which is what's important right now.
 
> You'll also note that I've alluded to interprocess locks.  At the 
moment
> it seems you have only looked at synchronisation between threads 
with
> a single process, but I think we also want to look at interprocess 
> synchronisation.

I've debated this one.  I'm not sure about this.  Not all platforms 
are going to have interprocess synchronization capabilities, for 
example.  In any event, so long at the interfaces prove viable adding 
interprocess mutex types won't be a big deal.

Bill Kempf