Practical uses for threads

Question

In your work, what specifically have you used threads for?

(Please give a description of the application and how the thread helped/enhanced the application.)

Answer 1

To scan directories looking for changed files. It is a lot quicker to spawn a thread per sub directory then do it in a single thread.

Answer 2

Most common use is for resposive UI like showing a progress bar for a long running background task.

Answer 3

Threads are critical for most UI work. Otherwise, any time you want to do a calculation or anything that takes a while, you will freeze the UI.

Therefore, most GUI frameworks have UI threads that handles the event loop (and some drawing activities), but most user code takes place in another thread.

Threads are also useful for occasionally checking things or making episodic changes to the state of the system.

Answer 4

Background tasks:

• Handling network connections and protocols.
• Doing Sound Synthesis running in the background of a multimedia application.
• Doing File-loading in the background in a multimedia application (CD streaming)

Other uses:

• Accelerating certain algorithms by running two instances of the same code in two different threads.

Answer 5

We have been using threads for several applications where the main screen was comprised of a workflow tailored to the currently logged on user.

Getting the workflow can be time intensive. Various parts of the workflow get loaded by different threads. For our main application BP/GeNA, about 11 threads are fired, each running a database query.

Regards,
Lieven

Answer 6

Handling concurrent client requests in a server.

Answer 7

I most commonly use threads when I want to do something with a bunch of resources that I know will take a long time, when there's no interdependence between the work to process the elements, and particularly if the bottleneck isn't a local resource (like CPU of disk). For example, if I've got a bunch of URLs to retrieve, each of those will go into a separate thread.

Answer 8

(Less serious answer) I like to use threads in any situation where I want the system to fall on its arse in interesting and unobvious ways, while still having plausible deniability as to how I could have let the problem slip through.

Or, in the words of Rasmus Lerdorf, "People aren't smart enough to write thread-safe code".

Answer 9

I know that most of the time I use threads, what I actually want to do is to launch some asynchronous lump of work - i.e. I want something to happen in the mythical "background". Unfortunately thinking about threads isn't really the correct level of abstraction for doing "launch some lump of work", because you're not putting something into the background. With a thread API you're creating another place to run stuff as a sibling of the process's original thread, and need to worry about what information is shared between them, and how, and so on. That's why I'm enjoying newer API such as Cocoa's NSOperation and NSOperationQueue. In the case of that API, launching some lump of work is just some single line, and the library takes care of whether a new thread should be launched or an old one reused.

Answer 10

This is a very general question. I've used "threads" to take potentially blocking work off of the UI thread, whether that work is local or network i/o or that work is computationally intensive tasks which will tend to "block" depending on the hardware it is run on.

I think it is more interesting to ask about a particular problem or pattern which help alleviates it and the applicability on threads, i.e.:

• how are threads relevant to model view controller?
• how or why should I take work off of a UI thread to ensure that the UI doesn't even think of blocking?
• how can a threadpool be useful for recursive (network) directory traversal as someone else alluded to?
• Should I be affinitizing threads for cooperative scheduling of computationally intensive tasks, or should I be using a ThreadPool and let the OS preemptively schedule the threads as it sees fit.

It's a pretty broad space and more clarity would likely help.

Answer 11

Threads are fundamental for most I/O bound applications, and for any reasonably complex server side application. Consider an application that acts as an exchange for information with multiple sources of data. You need to be able to deal with this information in independent threads, in particular if operations on this data is subject to latencies or require a signifigant amount of time to complete.

In most occasions threads often help to decouple various concerns within the application. A single thread dispatching events to interested parties will not scale well in the vast majority of occasions.

All but the simplest of applications will require threading to some degree.

Answer 12

I build web applications, so all code that I write is executed in multiple threads.

Answer 13

Our app is a web service, so we spawn off a thread per request. Technically, JNI spawns off the thread, but the code has to be thread-safe regardless. We've run into some interesting (FSVO) issues with both Hibernate and our ESB-based infrastructure, but for the most part keeping things in ThreadLocals and synchronizing on subsystem entry points has worked pretty well. We haven't tried more than a couple dozen simultaneous requests, so there may well be some race conditions we haven't identified yet, but overall we're performant and give the right answers.

Answer 14

I wrote a function that spawns a thread that beeps (from the speaker) at regular intervals to alert a test operator that something needs attention. After the modal dialog is responded to, the thread is killed.

Answer 15

Not employment related, but I'm doing some side work on the Netflix Prize. My computer has 8 cores and 20 GB of RAM ... running only 1 thread would be an utter waste, so I typically start 16 threads or so.