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