Re: Boost.Threads draft library submission

From: terekhov_at_[hidden]
Date: 2001-03-15 14:58:12

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., terekhov_at_y... wrote:
> > 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..
> 
> That's why I said "the usefullness of the 'portable version' is
> highly suspect".  However, there are other uses for atomic integer
> types.  For a simple example, the ref-counting done in shared_ptr
> needs to be thread safe.  An atomic integer type allows this to be
> done in an optimum fashion for platforms that support atomic
> operations and in a fashion that's at least as fast as traditional
> Thread Safe Object patterns for those platforms that do not have 
them.
> 
> I'm willing to remove atomic_t entirely, but for the reasons I just
> gave many thought the type would be useful for inclusion.
> 
> > 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".

> 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 ;-)

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

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

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

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

regards,
alexander.