Threading 101

6 Apr 2006 11:01 PM

Yuk Tang

Is there a basic guide to threading online? Something that not only
talks about the syntax, but also the concept and ideas related to it.
I'm still used to the school of single-thread programming, and I'm
interested in this.

--
Cheers, ymt.

6 Apr 2006 11:38 PM

Tom Shelton

Yuk Tang wrote:

> Is there a basic guide to threading online? Something that not only
> talks about the syntax, but also the concept and ideas related to it.
> I'm still used to the school of single-thread programming, and I'm
> interested in this.
>
>
> --
> Cheers, ymt.

Here is a good basic primer - but is in C#, so I hope that isn't a
hinderance.

http://www.yoda.arachsys.com/csharp/threads/

Don't let the C# scare you, because the actual concepts are pretty much
the same. There is lots of material on the web about threading. But,
I'm going to give you my advice as well :)

Avoid it if at all possilbe. If it can't be avoided - keep your
threading model as simple as possible and try to keep the shared
resources to a minimum. If you can, using the built in thread pool and
asyncrounous method calls (via delagates) is the cleanest. Threading
is a tool, but it is a dangerous one if not done correctly - and it is
realitively hard to get right (plus, it can sometimes make debugging
problems much trickier). Anyway, good luck :)

--
Tom Shelton [MVP]

7 Apr 2006 4:11 AM

Cor Ligthert [MVP]

Tom

> Avoid it if at all possilbe. If it can't be avoided - keep your
> threading model as simple as possible and try to keep the shared
> resources to a minimum. If you can, using the built in thread pool and
> asyncrounous method calls (via delagates) is the cleanest. Threading
> is a tool, but it is a dangerous one if not done correctly - and it is
> realitively hard to get right (plus, it can sometimes make debugging
> problems much trickier). Anyway, good luck :)
>

And to add something for Yuk to your messages so if you agree you can add
that next time as well. It makes maintainability mostly a lot more
difficult.

Cor

7 Apr 2006 4:56 AM

Tom Shelton

Cor Ligthert [MVP] wrote:
Show quoteHide quote

> Tom
> > Avoid it if at all possilbe. If it can't be avoided - keep your
> > threading model as simple as possible and try to keep the shared
> > resources to a minimum. If you can, using the built in thread pool and
> > asyncrounous method calls (via delagates) is the cleanest. Threading
> > is a tool, but it is a dangerous one if not done correctly - and it is
> > realitively hard to get right (plus, it can sometimes make debugging
> > problems much trickier). Anyway, good luck :)
> >
> And to add something for Yuk to your messages so if you agree you can add
> that next time as well. It makes maintainability mostly a lot more
> difficult.
>
> Cor

Very true...

--
Tom Shelton [MVP]

8 Apr 2006 10:22 PM

Michael D. Ober

Threading is useful if you have several different tasks that don't depend on
each other (very much). In this type of situation, the synchronization and
debugging issues aren't that difficult. Hoever, don't thread simply to
thread as this makes your debugging harder as well as forcing the system to
work harder. Remember, each thread requires system resources.

Still, you should learn how to handle and debug multi-threaded applications
as a lot of the .NET asynchronous callbacks are really executed on seperate
threads from your main application thread.

Mike Ober.

Show quoteHide quote

"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:%236GEfkfWGHA.4452@TK2MSFTNGP04.phx.gbl...
> Tom
> > Avoid it if at all possilbe. If it can't be avoided - keep your
> > threading model as simple as possible and try to keep the shared
> > resources to a minimum. If you can, using the built in thread pool and
> > asyncrounous method calls (via delagates) is the cleanest. Threading
> > is a tool, but it is a dangerous one if not done correctly - and it is
> > realitively hard to get right (plus, it can sometimes make debugging
> > problems much trickier). Anyway, good luck :)
> >
> And to add something for Yuk to your messages so if you agree you can add
> that next time as well. It makes maintainability mostly a lot more
> difficult.
>
> Cor
>
>
>

7 Apr 2006 12:50 PM

Yuk Tang

"Tom Shelton" <t**@mtogden.com> wrote in
news:1144366718.815826.308450@g10g2000cwb.googlegroups.com:
>
> Here is a good basic primer - but is in C#, so I hope that isn't a
> hinderance.
>
> http://www.yoda.arachsys.com/csharp/threads/
>
> Don't let the C# scare you, because the actual concepts are pretty
> much the same. There is lots of material on the web about
> threading. But, I'm going to give you my advice as well :)
>
> Avoid it if at all possilbe.

Thanks. So I'm following good programming practice after all, if
only through ignorance. Now if that were a straightforward and
consistent equation, I'm sure I'd be the best programmer in the
world.

I originally wanted to set several tasks going, and deal with
timeouts as they come. Now following your advice, I'm going the
linear route with checks at crucial points. This is also good
practice in forcing me to build objects a part at a time, testing
those parts before integrating them into the main object, then
testing the whole object before integrating into a larger system.

--
Cheers, ymt.

7 Apr 2006 12:48 AM

AlanT

Try Ted Pattison's articles on MSDN

http://msdn.microsoft.com/msdnmag/find/?type=Au&phrase=Ted%20Pattison&words=exact

'Basic Instincts' articles for May 2004, June 2004, September 2004 all
cover threads and threading.

hth,
Alan.