Re: Threads: what I wrote...

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-08 12:14:12

--- In boost_at_[hidden], scleary_at_j... wrote:
> OK.  It's time for my 2 bits. . .
> 
> > As for my comment...  you state a lofty goal here, namely to 
achieve 
> > thread safety internally and implicitly within an object.  We've 
been 
> > striving for some way to do this for years, and no one's yet 
found 
> > the answer here.
> 
> Agreed.  My perspective on this issue is a library component writer 
who
> strives for non-suprising yet efficient code.  As such, if I were 
to write a
> container class, say a singly-linked list (sllist), then I would 
*not* want
> to synchronize all access to any object of that class.  To do so 
would
> disrupt my efficiency guideline.  However, any globally-shared data
> (possibly referenced through the Allocator) should by synchronized, 
in order
> to keep the "non-suprising" guideline.
> 
> Again, coming from the library component writing perspective, there 
are
> three possible threading models:
>   Single - no thread sync support at all.  All calls to the library 
must be
> sync'ed by the user
>   Apartment - each object can be used by one thread at a time 
without extra
> sync'ing.  This requires the user to sync access to shared objects, 
and
> requires the library to sync access to hidden shared objects in the
> implementation.
>   Free - any object can be used in any way by any thread at any 
time.  The
> user never has to sync.
> 
> I am not sure if "Free" is even possible in C++.  It certainly 
would not be
> efficient.  That's why I prefer Apartment.

Agreed, though I dislike the terms you've chosen here.  The only time 
I've come across these terms was in COM development, where the 
classifications have other implications as well.  If this is a 
general set of terms that MS has perverted for COM I could be 
persuaded to use them, but if not, let's not go there ;).
 
> > The current "common" interfaces such as pthreads (I also dislike 
the 
> > fact that you put such emphasis on this library in the paper, but 
> > that's my own bias) all suffer from the fact that they are C 
based 
> > interfaces.  They don't fit well with classes, objects and 
generic 
> > coding practices.
> 
> IMO, pthreads is a good example of object-oriented C.  Object = 
data +
> related functions -> pthread_mutex_t + pthread_mutex_init,
> pthread_mutex_destroy, pthread_mutex_lock, ...

Agreed, but this all implies too many restrictions on the OO model.  
The simplest example to give in this regard is the requirement that 
the thread creation routines take a function pointer and a void 
pointer as arguments.  No consideration is taken here for functors or 
class methods or varying arguments.  There's no concept of an "active 
object".  This has lead to numerous approaches to thread creation 
when using pthreads in C++.  Most use a very thin wrapper approach 
that may not be the best possible solution in an OO language.
 
> In fact, the related functions map so well to member functions that 
a
> wrapper class can be written almost without thought (error checking
> ommitted, but can be easily added):
>   class mutex {
>     private:
>       pthread_mutex_t me;
>       mutex(const mutex &);
>       void operator=(const mutex &);
>     public:
>       mutex() { pthread_mutex_init(&me, 0); }
>       ~mutex() { pthread_mutex_destroy(&me); }
>       void lock() { pthread_mutex_lock(&me); }
>       void unlock() { pthread_mutex_unlock(&me); }
>       bool trylock() { return !pthread_mutex_trylock(&me); }
>   };

Here's a classic example where OO was ignored in a simple wrapper.  
Is it possible to copy a mutex class?  If so, what are the semantics 
of the copy?  I'm not sure how the pthread structures behave when 
copied, but I know that Win32 mutex handles will cause no end of 
grief if you copy them with out duplicating them.