Subj : Re: Threads suck [Was: "delete this" question]
To   : comp.lang.c++,comp.programming.threads
From : Phlip
Date : Thu Jun 23 2005 03:17 pm

Christopher Benson-Manica wrote:

> Well, my specific intention for this thread is for it to take care of
> caching the contents of a file in memory as my program is starting.
> The main thread can't wait that long, because the program is a Windows
> service and the service manager isn't willing to wait forever for my
> program to start.  I know I could do this other ways, but is there
> really a big disadvantage to spawning a thread to handle the caching
> of this file?

Flirting with Deceased Equine Flaggelation Mode, but...

In your case you are a service, not a simple app, so your program already
solves concurrency issues, so one more shouldn't hurt.

But note that Win32 services uses the GetMessage() DispatchMessage() event
loop, so my multiplexing solution would still work.

Another principle here is to push as much work, creativity, and risk down to
the OS as possible. ReadFileEx().

Joe Seigh wrote:

> Well, it's a nice trick I suppose if you don't have threads.

Per the other posts: An event driven architecture is good whether or not you
thread, and threading should not be used to avoid supplying the good
architecture.

> Otherwise it seems
> a bit contrived and makes things more complicated than they need to be.
One of
> the reasons for threading is modularization as much as for asynchronicity
or
> concurrency.  It's to make things simpler.

And threads can break encapsulation, and force an object in one thread to
become aware of the private details and activities of an object in another
thread, waiting for it to release a semaphore.

(Before the denizens of cpt think I'm some kind of anti-threading zealot
newbie, I grew up developing for AmigaOS, which works like a modern embedded
system. Threads are necessary, and one false move with threads would send
the CPU into FIREWORKS_DISPLAY mode.)

> I think the main culprit is not so well
> thought out OO design and design patterns which cause more problems than
they
> solve.  The "anti-patterns" if you will.  I haven't messed with GUI
programming
> lately but the early MVC implementations in Java were atrocious and a
major pain
> to work with.   Probably if you had the GUI primatives designed by people
who
> understood threading a little better and knew the thread design patterns
useful
> for keeping out of trouble, not so many people would find multi-threaded
GUI
> programming quite so traumatic.

Are you implying that there are GUI architectures that thread each input
event as the _default_??

> And c.p.t. wouldn't have so many posts requesting
> information on deadlock detection (invariably by people doing OO
> GUI programming).

I rest my case.

-- 
  Phlip
  http://www.c2.com/cgi/wiki?ZeekLand

.