Re: [boost] Re: Boost.Threads draft library submission

From: Mark Rodgers (mark.rodgers_at_[hidden])
Date: 2001-03-22 15:05:51

> > 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.  

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.

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.

Mark