Boost logo

Boost :

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
> > thread safety internally and implicitly within an object. We've
> > striving for some way to do this for years, and no one's yet
> > the answer here.
> Agreed. My perspective on this issue is a library component writer
> 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
> 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
> 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,
> 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
> > 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
> > interfaces. They don't fit well with classes, objects and
> > 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
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at