Boost :

paquette_at_[hidden]

--
Jeff Paquette
paquette at mediaone.net
http://www.atnetsend.net
> -----Original Message-----
> From: williamkempf_at_[hidden] [mailto:williamkempf_at_[hidden]]
> Sent: Monday, July 02, 2001 8:58 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Not keen on Boost.Threads? [was: name of the
> "thread" type]
>
>
> --- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> > Apologies for taking so long to get back to you on this; I've been
> a bit
> > busy. (I recently installed a multiple-boot system on my
> workstation,
> > with the result that I spent most of last week playing musical
> chairs
> > with various bits of hardware and software, trying to get Linux and
> > Windows to play nice together.)
> >
> > williamkempf_at_h... wrote:
> > >
> > > --- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> > >
> > > > It also seems to be following the pthreads architecture too
> closely
> > > for
> > > > my taste. It doesn't really "feel" like a designed-from-scratch
> C++
> > > > library to me -- more like a thin OO wrapper around the pthreads
> > > API,
> > > > and an attempt to emulate it on Windows. (I'm thinking in
> > > particular of
> > > > condition variables, a pthread-specific concept that I don't
> think
> > > > belongs in a generic threading library.)
> > >
> > > This is ironic.  I'm the main developer on this (though I've
> gotten a
> > > lot of input from others) and I'm a Win32 programmer with little
> > > experience with pthreads.  The only thing in the library that is
> > > pthread-like instead of Win32-like is the condition variables, and
> > > this happens to be a major lacking in the Win32 API.  I don't
> know of
> > > any serious MT programmers on the Win32 platform that haven't
> rolled
> > > their own CV concepts because of this.  The CV concept is
> _required_
> > > to use a monitor pattern, which is one of the most flexible and
> easy
> > > to use synchronization concept in OO programs.
> >
> > Probably part of the problem for me is that I've had to work out
> > techniques for cross-platform multithreading myself, with no contact
> > with anyone else working on the same sort of thing, so I've probably
> > reinvented several wheels and ended up with different concepts and
> > terminology. I have no idea what a "monitor pattern" is, for
> example.
>
> Look it up :).  The Boost.Threads library describes it and gives the
> classic example, a bounded buffer that's read from and written to by
> different threads, implemented using the Boost.Threads library.
>
> > I've always found condition variables very complicated and
> difficult to
> > understand. Whenever I use them I always have trouble working out
> how to
> > make them do what I want. I find the Windows equivalent, events, to
> be
> > much more intuitive and easier to follow.
>
> Events are much more error prone and can't be used in a monitor
> pattern.  The reason for this is that they don't work in conjunction
> with an external mutex.  A condition variable does.  You lock the
> mutex first, then possibly do some work with shared data, then wait
> on the CV.  The wait operation first unlocks the external mutex, then
> blocks until the CV is signaled, then re-locks the mutex.  This
> insures that you retain exclusive access to shared data before and
> after a wait, but not during.  You can't do the same thing with an
> event with out causing race conditions.
>
> In any event, your unfamiliarity with how to use CVs is not a good
> reason to dislike the library or for us to remove them.  The CV
> concept is essential to most MT patterns and it was simply a mistake
> that Win32 never included one (that's coming from a Win32 programmer
> with no POSIX threads experience, remember).  In fact, every Win32
> programmer roles their own as soon as they learn what one is.  The
> problem is, rolling your own is tricky and usually isn't done
> correctly.
>
> > > In fact, I'd expect more people to accuse the design of being too
> > > Win32 biased.  For instance, the design of the Semaphore includes
> a
> > > max setting and methods to increase the semaphore value by
> variable
> > > amounts instead of one at a time.  Another example is the design
> of
> > > the thread class itself, which allows for multiple join() calls
> and
> > > has no concept of detach().  I could continue with this list, but
> I
> > > think you get my point.
> >
> > Well, no, not really. The whole "join()/detach()" concept is pthread
> > specific.
>
> No, it isn't.  The terminology is POSIX terminology, though we use
> slightly different meanings here.  However, Win32 still has these
> concepts under different names.  A join() is just a Wait*() operation
> on the thread handle.  A detach() is just a CloseHandle() operation,
> though Win32 HANDLES are ref-counted changing this slightly from
> POSIX, but possibly not from the meaning in Boost.Threads.
>
> > > > (When I have a bit more spare time, I'll polish up my own thread
> > > library
> > > > and post it somewhere for comparison.)
> > >
> > > I'd be interested in seeing this, but it may be better for you to
> > > point out specific things in the current implementation you'd do
> > > different.
> >
> > Looking back at the path the design has been taking recently, I
> suspect
> > we've diverged too far. I can't understand the liking so many people
> > have for the "thread_ref" concept. Non-copyable objects, with smart
> > pointers when necessary, are the standard C++ idiom for this sort of
> > thing; why treat threads differently? I'm afraid I Just Don't Get
> It.
>
> Why are Win32 handles ref-counted concepts, with DuplicateHandle?
> _That_ is why people feel more natural with a ref-counted design.
> That said, I've been swayed since the initial design that this
> probably isn't a good thing.  I guess this particular argument isn't
> dead yet.  I just find it surprising that you prefer noncopyable
> types when Win32 types are both copyable AND ref-counted (with the
> ability of the user to choose which type of copy to do).
>
> > Anyway, in case anybody's interested, the current state of my
> threads
> > library can be found at:
> > http://storm.net.nz/~ross/c++/rs_threads.tgz
>
> I'll have to look at this later.  However, if you don't have CVs then
> that's at least one thing that our two implementations will have to
> differ on.  You *really* should get to know CVs.  You'll never touch
> a Win32 event object again.
>
> > I'll probably add a few more bits to it -- there's no semaphore
> class at
> > the moment, and I'm dithering over whether some sort
> of "synchronised
> > smart pointer" template would be a good idea.
>
> My vote is no ;).  However, I'm sure Boost will have one at some
> point, because some people do like them.
>
> > (I've made one major change recently: prompted by this discussion, I
> > took a more careful look at my design, and (among several smaller
> > changes) decided that abandoning ("detaching" in pthreads jargon) a
> > thread was never a reasonable thing to do. The Thread class's
> destructor
> > now blocks instead of abandoning a still-running thread.)
>
> This was a bad decision.  Think of the Win32 AVI display control.
> This control spawns it's own thread to display the video frames, and
> the lifetime of this thread is not bound by any programmatic block.
> It really should be a detached thread (and BTW, abandoned is not the
> proper Win32 terminology for this).
>
> Bill Kempf
>
>
> Info: http://www.boost.org  Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>