Re: Threads

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 
think 

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 
c++)
> 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 
interested.

> I looking for a good one for many times and I collect
> a few:
> - http://www.cs.wustl.edu/~schmidt/patterns-ace.html 
>   (also interesing to read
> http://www.cs.wustl.edu/~schmidt/patterns.html)
> - http://www.gncz.cz/kra/README.html
> - http://www.objectspace.com/products/cppFoundations.asp
>   this is a very good one (at least the design philosophy), but has 
>   some implementation weekness it useful to see other toolkits, like
>   http://www.objectspace.com/products/prodCPP.asp
> - http://www.roguewave.com/products/threads/
> - http://www.ooc.com/jtc/
>   this's the java thread model and real good one.
> - http://cplusplus.sourceforge.net/
> - http://threads.sourceforge.net/
> - http://world.std.com/~jimf/papers/c++sync/c++sync.html
> - http://www.cs.wisc.edu/~stanis/tthread.html
> - http://user.tninet.se/~dpn659b/threads.html
> - http://zthread.sourceforge.net/

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.