List Info

Thread: ReaderWriter or Lock




ReaderWriter or Lock
user name
2006-07-21 13:58:06
On Fri, 21 Jul 2006 13:35:20 +0100, Ian Griffiths
<ianINTERACT-SW.CO.UK>
wrote (amongst other things):

> ... there often are no good 'one size fits all'
answers.

That holds true for almost all of multithreaded programming.
 There are
the specific rules that restrict what a thread can do or how
it can do
something (and some are still presumed and debated ; but,
largely there
isn't any specific guidance for multithreaded programming. 
There are
patterns that can be used; but, most times they don't
exactly fit in the
problem domain of the application you're working on (for
many reasons).

Which is probably why the biggest problem area, even with
senior
programmers, involves multithreading.

In reality, multithreading hasn't really been used in
Windows applications
that long.  It used to be the one thread and that was just
the message
pump.  Everything was done in response to processing one of
many messages
in a limited-sized queue.  If something was expected to take
a long time
to perform, the hourglass/wait cursor was shown.  And to a
certain extent
this is perpetuated by Windows.  Windows XP, for example,
creates
the "Ghost Window" for programs whose GUI is
unresponsive (usually because
they're not multithreading, or not doing it correctly).

For the most part, even in multithreaded applications,
programmers work on
synchronous code, rarely touching the asynchronous code. 
Often times the
asynchronous code is voodoo code, someone got it to the
point "well, it
works doesn't it?", but they don't know why and they
don't want to touch
it for fear of breaking it.

If you're like me, and consult on many different projects,
Joe Newcomer
has some excellent (Win32/MFC-centric) articles, including
"The n Habits
of Highly Defective Windows Applications" [1] that
details some tell-tale
signs that voodoo programming is amok in your project. The
article alludes
to a few keywords you can search for in the code to tell if
the code is
reliable and robust and where to start looking for problem
areas.

[1] http://www.flo
under.com/badprogram.htm

-- Peter
Microsoft MVP, Visual Developer - Visual C#
http://www.peterRit
chie.com/blog/

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )