By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,877 Members | 1,064 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,877 IT Pros & Developers. It's quick & easy.

Threading 101

P: n/a
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.
Apr 6 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a

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]

Apr 6 '06 #2

P: n/a

Try Ted Pattison's articles on MSDN

http://msdn.microsoft.com/msdnmag/fi...on&words=exact

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

hth,
Alan.

Apr 7 '06 #3

P: n/a
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
Apr 7 '06 #4

P: n/a

Cor Ligthert [MVP] wrote:
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]

Apr 7 '06 #5

P: n/a
"Tom Shelton" <to*@mtogden.com> wrote in
news:11**********************@g10g2000cwb.googlegr oups.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.
Apr 7 '06 #6

P: n/a
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.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2****************@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


Apr 8 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.