Re: Threads: what I wrote...

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-10 08:58:45

--- In boost_at_[hidden], jsiek_at_l... wrote:
> William Kempf writes:
>  > interface are specified.  The "mutex" may not be a template, but 
the 
>  > mutex concept is applicable to varying concrete types that may 
be 
>  > used in templates.  Do I have this right?
> 
> Yes, that is right.

I hope I don't get in peoples' way here.  I've got 5 years experience 
with threads, so even though I'm not an expert I think I've got 
enough qualifications to be discussing this here.  I'm new to this 
sort of design practice, though, so I may come across as ignorant and 
may even slow the process down from time to time.  If anyone thinks 
I'm "not getting it", please e-mail me directly to discuss the 
concepts I'm missing.  I thank you for this illustration and I think 
I've got a better handle on what's being asked for now.

>  > The documents look nice, and I like the approach taken for the 
>  > try_lock.  I'm still curious if a timed_lock should be 
considered.  
>  > The benefit of a timed_lock over a try_lock is that the CPU 
>  > utilization can be vastly reduced for some constructs on some 
>  > platforms.  Yes, that's starting to get specific to the 
>  > implementation, which I don't want to do, but it still seems a 
valid 
>  > question.
> 
> Yes, I think a timed lock deserves a place of its own. I'm not
> sure whether it should just be added to the Mutex concept, or
> do something like TimedMutex which is a Mutex with a timed lock.

That's a good question, but it begs whether or not the try_lock 
should not have been handled like wise.  Also, if we include a 
timed_lock I don't think we need a try_lock, since it's equivalent to 
a timed_lock with a timeout of 0.

>  > The only comment I'd make on the docs as written at this time is 
that 
>  > the destructors may need a precondition.  It's possilbe (though 
>  > probably not desirable) to create the lock on the heap and pass 
it to 
>  > another thread which deletes it.  This means a thread is 
attempting 
>  > to remove a lock that it doesn't own, which probably should be 
an 
>  > error?
> 
> So what exactly should the precondition be? (sorry for being dense)

That the mutex is locked by the thread calling the destructor.  On 
some platforms it's not possible for the "native mutex" to be 
unlocked by a thread that did not do the locking.  DBC (which this is 
a watered down form of) would therefore require that this be a 
precondition.  This is a very minor corner case, one that shouldn't 
occur in practice any way, but it would still be nice to cover it in 
the documentation.

William Kempf