Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-18 10:21:12

--- In boost_at_[hidden], "Levente Farkas" <lfarkas_at_o...> wrote:
> --- In boost_at_[hidden], "William Kempf" <sirwillard_at_m...> wrote:
> > Someone else wanted to start with the primitive types that should
> be
> > defined, so I'll start there. The primitives I think that should
> be
> > defined as class objects:
> >
> > thread
> > mutex
> > semaphore
> > condition
> >
> > That's it. No more, no less. Let me address each and why I

Boy... I hope you've read the numerous postings that have been sent
since this one! :)

> first of all I think we realy need a _good_ C++ (which means real
> thread library.

I think we all agree, though there may be some disagreement as to
what "real C++" means. I think we've got a good start though.
Jeremy Siek has several documents on thread concepts that we've been
discussing (ask him for the URL... since it's on his own site and
we're still modifying them often I won't personally give them out).
I've also got a full Win32 implementation of the primitives that
exist so far and we'd be happy to share the code with anyone

> I looking for a good one for many times and I collect
> a few:
> -
> (also interesing to read
> -
> -
> this is a very good one (at least the design philosophy), but has
> some implementation weekness it useful to see other toolkits, like
> -
> -
> this's the java thread model and real good one.
> -
> -
> -
> -
> -
> -

I've been to most of those several times. You did find a few new
ones for me, and for that thanks! :)
> I agree with Dietmar (as usualy) that we have to
> - A clear statement of our goal.

Not complete, but I think we've come close thanks to Dietmar.

> - A decription of techniques, idioms, pitfalls, etc. related to
> achieving this goal.

We have this started, though many of them must remain undocumented
until after we come to consensus on many of them. What's been done
in the past has not always been good, especially where C++ is
concerned. Expect this part of the process to move slowly.

> - A set of interfaces used by those techniques and idioms.

On our way here. Again, ask Jeremy for the URLs for the models we
have so far.

> - Possibly a simple [demo] implementation.

Also on our way with this one. Like I said, if you want to see
preliminary code for Win32 just e-mail me.

> before any further work. IMHO we need a thread, mutex and condition
> first.

The thread will actually be one of the last things we tackle. To
many people here it's more important that we have the synch
primitives so that they can write thread safe library code.

> about the semaphore, it's depend what do you mean by semaphore?

Typically when you say semaphore you mean a counting semaphore. I'm
used to Win32 where that's the only definition of a semaphore, so I
didn't spell things out like I should have. So far the semaphore has
taken a back seat to the other primitives (Mutex and Condition).

> on win32 the mutex is system wide and critical-section is process
> wide, on unix mutex is process wide and semaphore are system wide,
> but I think these are just different type of mutecies.

Actually, with pthreads the mutex can be system wide as well. The
Unix semaphore is also a counting semaphore, AFAIK. So it's
not "just a different type of mutex".

> about rw-semaphore. yes we need and more monitor, barrier, auto
> guards, timers and more, but first at least the basic have to be
> properly defined, it'd be a nightmare the write something useless
> (like valarray in std).

An rw-lock is a possibility, though I don't think it's mandatory.
I'm not at all convinced we need a first class monitor. I'd prefer
to just use the monitor as a pattern, implementing the pattern with
the mutex and condition. Barriers mean different things to different
libraries. In some a barrier is a gate, a synch object that's either
open or closed and threads can wait until it's open. In others a
barrier is a what I think you're calling an auto guard. I'm not sure
we need a gate, and the auto gaurd is the ONLY way to lock a mutex in
our current design. I also see little need for timers. One thing
you didn't mention which I think should be our next focus is an
atomic counter.

> another thing that posix and win32 thread api
> are very different so it'd have to designed very carefully in order
> not to loose performance and feature and still keep platform
> independent (at least on interface level).

Agreed. I think we're headed in the right direction, though until we
have a portable implementation I'm sure we'll be discovering little
issues frequently.

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