Date: 2001-03-15 15:18:25
--- In boost_at_y..., terekhov_at_y... wrote:
> --- In boost_at_y..., williamkempf_at_h... wrote:
> > --- In boost_at_y..., terekhov_at_y... wrote:
> > > IMHO it is a misuse of concept to provide a library, which would
> > > just add full bloat lock/unlock to non-interlocked ops.
> > The goal is to provide implementations that DON'T do "full bloat
> > lock/unlock" when ever possible (which should be most of the
> I understand the goal, however, I think that you miss the problem
> here. "atomic_t" would only work if it would insure proper memory
> visibility and restricted compiler optimisations (something along
> the lines of Java's revised memory model and "volatile" with memory
> barriers). Anyhow, library is a wrong place - it should be defined
> on language level. If you need a win32 optimised "ref-counting done
> in shared_ptr" - ok, please do it, but name it something like
I haven't missed the problem. The C++ "volatile" with platform
specific memory barriers (a concept I've been considering for a later
phase of Boost.Threads) will make "atomic_t" compliant on platforms
that must have the poor "mutex implementation". In practice I expect
we'll never really use the poor implementation. It exists in the
code solely as a fall back for specific platforms until they can be
addressed in a more appropriate manner.
As for library vs. language.... (1) anything the language can do in
this regard the library can do, even though this is not always the
case for other things (2) we can't change the language here, we can
only supply interfaces with library implementations that could be the
basis of language changes if deemed worthy.
You also miss the point with "synch_counter_t". First, Win32 is
hardly the only platform that can support atomic integer operations.
I expect most can, it's just not something that's portable. That's
why a portable interface is needed here! Second, the ref-counting
example was just the simplest example available to point out how
atomic integer types can be used effectively even if native support
is not available.
> > The implementation I used is a variation on the ACE
> > which is still considered the most accurate implementation
> > on Win32.
> I respectfully disagree ;-)
Then provide alternatives. I've done the research and have found
none better. In fact, most are abysimal. The only two that come
close to correct are ACE and pthread-win32, which have nearly
identical implementations in the latest available source.
> > I'll address some points made in the link you gave above:
> > 1) Spurious wake ups are allowed and expected.
> spurious wakeups are OK with Posix condition variables.
> the problem is that ACE/pthread-win32 impl. does not
> track the number of already signalled waiters. So that
> "signal" may induce one spurious wakeup,
> "broadcast" may induce multiple spurious wakeups.
> this is not a question of correctness but rather efficiency.
Which, especially at this stage of the game, is a non-issue.
> > 2) The unfairness is very closely related to spurious wakeups,
> yes, indeed, it is very closely related. but here again the problem
> is that signals get consumed in "unfair" fashion by some threads
> multiple times (as non-detectable spurious wakeups) and some threads
> could remain blocked on condition variable (BTW, that violates
> CV "atomic" semantics with respect to mutex and other threads
> calling signal/broadcast).
Neither POSIX, nor more importantly Boost.Threads,
gaurantees "fairness" in this regard. It's a noble goal, and if
you've a solution to attain it I'll gladly do so, but it's not a
requirement. (BTW, I don't see how the CV "atomic" semantics are
> > With out knowing what
> > the "correct solution" is, I see little difference between the
> > I'll try to code up the example given in the link using
> > to see if the reported problem is even reproducable, but if you've
> > got an implementation that's supposed to be more correct it would
> > save me time here.
> i've posted multiple solutions (hopefully correct ones) to
> comp.programming.threads/pthread_cond_wait() and WaitForSingleObject
> if you want, i can post it here or send it directly to you..
Either would be helpful.
> > > 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.
> > I don't agree with this approach at all. First, it violates the
> > Boost criterion of not being reliant on third party libraries that
> > would need to be down loaded by users. Second, it adds another
> > of overhead to the Win32 implementation which causes some
> > speed problems (though I must admit that it may be more due to my
> > pthreads implementation of Boost.Threads than to the extra level).
> > Third, the goal is for the interface to be implementable on
> > platforms, many of which won't have pthreads support. By
> > implementing the Win32 version directly instead of using pthreads-
> > win32 I get some indication of whether or not that goal has been
> well, PTHREADS is not a third party library - it is an open
> the same as C++ including standard library and AFAIK is the only
> one (_standard_) related to threading in existence so far.
It's a third party library, even if said party is a standards
committee. Pthreads do not exist on all platforms. Even on those
platforms where pthreads exist they may not be supplied by the
compiler and/or OS. As such the pthread library can not be a
requirement of a Boost library, including the Boost.Threads library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk