From: scleary_at_[hidden]
Date: 2000-08-08 10:26:56
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.
> 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, ...
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); }
};
-Steve