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
> 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:
note: the fix is outdated there are better solutions - see:
pthread_cond_wait() and WaitForSingleObject()
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk