Fog Creek Software
Discussion Board




MultiThreading

hi ,
i started learning about multithreading(using java) last week and found it very interesting.
just want to know ur thoughts on multithreading and any good references.it appeared to me like ,multithreaing can only be exploited with multiple processor CPU's.

regards
mrc

MRC
Thursday, November 21, 2002

Mrc,

On a single processor you can still have virtual multithreading, where the processor switches between two tasks.  This is how Windows is apparantly able to have several applications running at once.

For the programmer, multithreading is great for reducing complexity.  Especially when dealing with a graphic user interface.

Take, for example, animated gifs in a web page.  Writing a single process to animate six or seven images on a page would be possible, but the code complex. 

With multithreading you can have a single thread for each image that simply wakes up after a set time and loads the next frame.  About 5 lines in java.

The disadvantage to this is that you increase overhead, which can have a performance cost.

Ged Byrne
Thursday, November 21, 2002

See this article at kuro5hin, http://www.kuro5hin.org/story/2002/11/18/22112/860 . I don't necessarily agree with all of it, but it does make some valid points.  The discussions are fairly enlightened at points as well.

Steve Barbour
Thursday, November 21, 2002

I/O bound applications can also benefit from multiple threads, even on uniprocessor machines, or in any system where the number of threads exceeds the number of physical processors.  The classical case is a server that handles a set of network connections, alternating between doing calculation and waiting on I/O.  On an N processor machine, N threads can be calculating while M threads are waiting on I/O.  Even where N = 1, you *may* get an increase in throughput, esp. if the ratio of calculating time to I/O wait time is large.  Writing the code for this with threads *can* be simpler than writing it as a state machine, which is the typical single-threaded approach. 

The chief advantage to threads here is, given the appropriate OS and thread implementation, the system will automatically use more processors if they are added to the system. 

James Montebello
Thursday, November 21, 2002

We use multithreading here whenever we have a process that is going to take some time to complete.  We put that process into a second thread, allowing the application to continue to run in the main thread.

This prevents "blocking" that makes an app otherwise unresponsive during a long operation.

If the app cannot continue until the running process completes, we use a global variable to allow us to tell the user "you can't continue right now."  However, the app is still responsive.

Without this multithreaded behavior, a user would be more apt to think the app has frozen.

Karl Perry
Thursday, November 21, 2002

With Java, you'll use threading for Swing programming. Swing is not thread safe & you need to understand threading to make your apps work. I just finished fixing a threading bug in a Swing program I inherited.

Look at Doug Lea's book, Concurrent Programming in Java, 2nd ed. Slim in size, dense in ideas. He supports a useful library for concurrent programming.

jq
Thursday, November 21, 2002

That "story" on kur5hin.org is one of the biggest stinking piles of dung I've ever read.

If threading makes your life simpler - and for many applications it will - then use it.  That's how you know if you're using threading properly:
It simplifies your code for similar or improved performance.

Nat Ersoz
Thursday, November 21, 2002

In addition, to say "For the programmer, multithreading is great for reducing complexity. Especially when dealing with a graphic user interface." is only half the story. Multithreading _can_ reduce code complexity, but it also makes the runtime behaviour of your program less predictable. This means you have to be damn sure you've dealt with any concurrency and resource locking issues.

Are any of your threads reading and writing the same data? Can you be absolutely sure that they won't try to do it at the same time? Are you absolutely positive that you put all the relevant pieces of code within critical sections? etc.

Adrian Gilby
Thursday, November 21, 2002

A second vote for Doug Lea's book. Highly recommended if you're working in Java.

Yves
Friday, November 22, 2002

The kur5hin.org article is very specific to Unix programming.  In Java you don't have this Thread/Process distinction he is discussing. 

Besides, the whole Java object mechanism provide the event driven approach recommended as a solution.

So the article just isn't applicaple to Java programming.

There is, however, a lot of pitfalls involved in thread programming. 

Josh Bloch's Effective Java has a very informative section on Threads.

http://www.amazon.co.uk/exec/obidos/ASIN/0201310058/ref=sr_aps_books_1_1/202-1782066-4017408

Ged Byrne
Friday, November 22, 2002

>> That "story" on kur5hin.org is one of the biggest stinking piles of dung I've ever read.

Agreed.  Mostly, he demonstrated that it's hard to make code thread-safe after you write it.  Which can be true.  But retro-fitting design constraints is always harder than including them up front.

If you know what you're doing, and you properly encapsulate, the thread safety part isn't that hard.  You learn the techniques, then you get into the habit of making your classes thread safe.  Avoiding deadlocks can be tricky, though.  You really have to think that part out ahead of time.

Brian
Friday, November 22, 2002

I mostly agree with the kur5hin article.  The fundamentals of concurrent programming are not that difficult, but translating those concepts into robust code is hard.

Threading has become a "separate the men from the boys" issue, which is unfortunate, as this leads to its application where it may not be necessary; kind of a badge of honor.  Maybe this attitude isn't prevelant, but I've seen it at my company.

Bugs have a progression:
1. Programmer screws up
2. QA or user finds the error
3. Someone fixes the problem

For tasks where the time from step 1 to 3 is lengthy and or painful, I like to see a more senior persion doing the work.  Threaded code often falls into this category.  There's instances where experience gives you a queasy feeling about something.  Recently, I was reviewing some code where the developer was doing heavy file access in a worker thread.  At certain points, he was calling SuspendThread on this thread.  Even though this is supposed to work and usually does, it's still a "bad idea" on many levels.  Until someone gets that queasy feeling, they shouldn't write heavily theaded production code.

I think the author was trying to convey that most of the time, you don't need threading, just like most of the time, you don't need multiple inheritance, templated code (besides STL), function pointers, file system hooks, XML, etc.

Bottom line:  Identify the need and apply the minimum level of complexity required.

Bill Carlson
Friday, November 22, 2002

From my experience I would say: "Use as less threads as you can. If you need more then two threads - think twice". All above is NOT true if all your threads are COMPLETELY independent, but this is very rare situation.

dk
Sunday, November 24, 2002

Can anybody recommend a good book on threading issues in general? Particularly with C++ and a Windows programming environment?

I also have to agree with the comment of "the less thread you end up using the better" as a rule of thumb.  Or at least from my limited experience using threads in Java.  Basically yes, threads can be nice but don't go thread happy.

- Raist

Raist3d
Monday, November 25, 2002

Here's the book I learned win32 threading on:

http://www.amazon.com/exec/obidos/tg/detail/-/0201442345/ref=pd_sim_books_1/002-9993785-2739234?v=glance&s=books

Excellent discussion of the issues involved, and spends a good deal of time with MFC, which was important at the time.

O'Reilly also had a book on threading on Win32, but it's listed as out of print. I haven't read it, but I know one of the authors (Mike Woodring) and he really knows his stuff.

Chris Tavares
Monday, November 25, 2002

Thank you very much Chris!  I'll definitively check it out.

Raist3d
Tuesday, November 26, 2002

I've always found "Principles of Concurrent and Distributed Programming" by Ben-Ari very useful for fundamental concepts - I don't know if it's still in print. Also the following papers:

Dijkstra, "Cooperating sequential processes"
Hoare "Monitors" and "Communicating sequential processes". The one by Dijkstra is online at:

http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF

There are at least two implementations of Hoare's CSP in Java:

http://www.cs.ukc.ac.uk/projects/ofa/jcsp/
http://www.rt.el.utwente.nl/javapp/

Andrew Simmons
Tuesday, November 26, 2002

To conclude multithreading is useful in the following cases(even on single processor machines):

--> multithreading is good for reducing complexity,especially when dealing with a graphic
user interface. but it also makes the runtime behaviour of the program less predictable.concurrency and resource locking issues need to be dealt with properly.
--> I/O bound applications can benefit from multiple  threads.
--> For making the long time taking applications more responsive to the users.
--> Use multithreading only where it is necessary

MRC
Friday, December 06, 2002

We are trying to speed up the sending/receiving of SMS by multithreading.

In lieu of this we propose to thread the main application itself by having multiple instances of a provider-listener (one per thread) each listening at different port.
1)Since the API is implemented to start a worker thread which is responsible for socket management, can we intialise a service provider thread at a predefined port ( other than 4000 ) by using TDapi_InitM(xxxx)??

ANYONE please let me know if this is possible. Else please let me know other options (apart from threading the call back functions) for speeding up transactions.

bASICALLY ITS LIKE THE YAHOO IM, OR ICQ. we have to have lots of listners. right now I have queuing, which is rather very slow.

Anyone who can help will be very much appreciated.

Plz

Regards,
kris

k.spencer@eudoramail.com

kris spencer
Sunday, February 15, 2004

*  Recent Topics

*  Fog Creek Home