From: Levente Farkas (lfarkas_at_[hidden])
Date: 2000-08-23 09:10:10
Jens Maurer wrote:
> I think that no amount of library or language wrapping that does not
> cripple usefulness can avoid that the programmer has to understand
> what's going on, and that means getting acquainted with the complexity.
> This is unlike std::map, where the user doesn't have to understand
> red-black trees (I don't) to use them correctly (I hope I do
> sometimes).
>
> I think that striving for compile-time support for error detection
> is a good idea in general (that's why we're using a statically-typed
> language), but not very applicable to the problems with threading,
> which are run-time dynamic in their most intrinsic nature.
>
I agree. those who don't understand _and_ don't have mt experiance
never will use any thread library in a right way and in am efficient
way at the same time. we never have to loose efficiently and usability
just because of it has some general compile time reason.
> - Allow for simple implementations: If the user doesn't need
> a recursive mutex, don't force one on him (thus forcing the
> underlying system-specific implementation to possibly craft one
> together expensively). If the user only needs a critical section,
> don't force a monitor on him.
I don't agree with it, I don't know any reason why we have to support
non-recursice mutex. even if the underlying os don't have it, there is
a minimal overhead of this.
> - Hoare's monitor pattern says that the mutex must be locked
> around notify() to avoid race conditions. Even though pthreads
> doesn't seem to require this, it's still a good idea to follow the
> textbook pattern, I think.
agree again.
> - Start thinking about higher-level synchronization abstractions
> between threads, for example type-safe (message) queues, and think
> about what medium-level options for their implementation should
> exist (mutex, monitor, semaphore, etc.).
> - Provide a really broad choice of options (recursive vs. non-
> recursive mutex, read/write mutex, atomic counters, several
> types of monitor), have a trial phase where users implement their
> favorite abstract data types / application / whatever with these and
> then remove the obviously unused ones.
broad but not too broad, if the library design by peopel who already have
mt experiance, this can be a minimal basic for higher level abstraction.
there will always people who'll use those "not realy used part" and in
this case the revocation won't so simple.
> - Write down the patterns you're trying to introduce. Nowadays,
> someone writes "singleton" in a comment at the top of some class
> and I can basically skip all the details because I know how it
> should work. The goal here is exactly the same: Someone writes
> "monitor" on top of some class and the reader should know what's
> going on.
yes. the first and most important part is a good documentation.
that's why I realy like Jeremy's pages...
-- Levente http://petition.eurolinux.org/index_html
"The only thing worse than not knowing the truth is
ruining the bliss of ignorance."