Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
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 
time).
> 
> 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 
> "synch_counter_t".

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 
implementation,
> > which is still considered the most accurate implementation 
available
> > 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 
violated here.)
 
> [...]
> > With out knowing what
> > the "correct solution" is, I see little difference between the 
two.
> > I'll try to code up the example given in the link using 
> Boost.Threads
> > 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 
> level
> > of overhead to the Win32 implementation which causes some 
noticable
> > 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 
numerous
> > 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 
> met.
> 
> well, PTHREADS is not a third party library - it is an open 
standard 
> 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.

Bill Kempf