Re: [boost] Re: Not keen on Boost.Threads? [was: name of the "thread" type]

From: Ross Smith (ross.s_at_[hidden])
Date: 2001-07-02 18:14:01

williamkempf_at_[hidden] wrote:
> 
> --- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> >
> > 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 :).

Where? David Butenhof's book never mentions it, and Google just gives me
a bunch of links to VDU vendors. Can you point me to a web site that
describes it?

>  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 just looked through every document I could find in the threads
library, and I can't find any mention of it. Unless you mean that big
PDF document, but I'm afraid I draw the line at holding my head at 90
degrees long enough to read the thing.

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

Please justify that claim.

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

I have no idea what you mean here. Win32 types -- I assume you mean
HANDLE -- aren't copyable (you have to use DuplicateHandle()) or
reference counted (you have to manually track them and call
CloseHandle() exactly once for each handle).

And incidentally, I'm getting a bit tired of your assumption that any
disagreement I have with your approach must be due to a Windows bias on
my part. I've been programming for both Windows and Unix for quite a few
years, and any bias towards one or the other exists, I believe, only in
your imagination. Difficult as it may be for some people to accept, it
_is_ possible to believe that there could exist (gasp! blasphemy!) a
flaw in the Unix approach to something without actually having been
assimilated by the Borg. :-)

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

Now who's showing their Windows bias? :-) Just because Microsoft
implemented a bad design (gee, who'da thunk it?) is no reason for me to
follow suit.

> It really should be a detached thread (and BTW, abandoned is not the
> proper Win32 terminology for this).

I don't recall claiming that it was.

-- 
Ross Smith <ross.s_at_[hidden]> The Internet Group, Auckland, New Zealand
========================================================================
"Unix has always lurked provocatively in the background of the operating
system wars, like the Russian Army."                  -- Neal Stephenson