Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-15 10:10:51

--- In boost_at_y..., terekhov_at_y... wrote:
> --- In boost_at_y..., williamkempf_at_h... wrote:
> > --- In boost_at_y..., <boost_at_y...> wrote:
> [...]
> > At this point I'm open to any and all criticisms.  It's time for 
me 
> > to step back from the work I've done and seriously consider ideas 
> [...]
> > Bill Kempf
> 
> interlocked (atomic) stuff is non-portable ("portable" version 
> with mutex has completely different semantics)

How are the semantics different.  They pass the unit tests, which 
should show the semantics to be the same.  The usefullness of 
the "portable version" is highly suspect, but many thought that 
atomic operations were needed even if some platforms fell back on the 
slower mutex implementation.

> POSIX CV impl. is incorrect (see comp.programming.threads)

Care to explain this?  comp.programming.threads is not much of a 
pointer to find something like this, especially since you give no 
clue as to why you find it "incorrect".  Links to specific threads 
would be more beneficial.

> mutex impl. is looking quite strange (2 "real" mutexes + CV ??)

This is simply necessary for insuring either checked locking 
semantics as found in boost::mutex (which is something I'm open to 
discussing as to whether it should be checked instead of unspecified) 
or recursive locking as found in boost::recursive_mutex.  Unless 
POSIX gauranteed such behavior in some manner the "strange 
implementation" is necessary.

> how about return code checks?

A valid point.  Someone more familiar with pthreads should address 
this, raising an exception in all likelyhood.  Thoughts from others?

Bill Kempf