Re: Boost.Threads draft library submission

From: terekhov_at_[hidden]
Date: 2001-03-15 12:23:37

--- In boost_at_y..., williamkempf_at_h... wrote:

> > 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.

interlocked calls (ops/instructions) are _usually_ used either 
in order to avoid relative expensive synchronization or in order 
to implement synchronization primitives themselves - e.g. 
spinlocks/mutexes/semaphores/... (things like: load, calc_new, 
compare_and_swap - too late: try again..) and require careful
use of other non-portable things such as memory barriers, etc..

IMHO it is a misuse of concept to provide a library, which would
just add full bloat lock/unlock to non-interlocked ops. 

> 
> > 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.

ok. sorry. why I find it "incorrect" - link:

  http://sources.redhat.com/ml/pthreads-win32/2001/msg00015.html

  note: the fix is outdated – there are better solutions - see:

specific threads: 

  pthread_cond_wait() and WaitForSingleObject()

and

  pthread_cond_* implementation questions

> 
> > 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.

the checks are only needed (if at all) in debug mode.
POSIX threads standard (and coming SUS) does have recursive mutex.

in general, i would suggest that you simply adopt POSIX threads
programming model and just provide C++ wrappers on top of POSIX 
threads API (you may add things such as win events, etc on top
as non-portable features) and spend some energy trying to bring 
pthreads-win32 (POSIX threads impl for win32) in "production 
ready" state so that the boost threads library would simply use 
pthreads-win32 under windows.

regards,
alexander.