From: Ross Smith (ross.s_at_[hidden])
Date: 2001-07-02 18:14:01
> --- 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
> 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
> 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
> > 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk