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
> > 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk