Multi-threaded programming with a Single (extra) thread_问答_开发者

I was contemplating the idea of using a single looping thread function to utilize multithreaded programming. However, it's plain theory so I wonder what are your ideas since it's probably wr开发者_Go百科ong.

An example might be that a single function is called multiple times in scattered places around an application. While it would be hard to make parallel programming simply on it, one could have an extra thread that loops with a boolean that checks "do we need this function", and if yes, then to execute it.

Is that even remote possible to have applications?

I suspect it will be slow due to some "lag" between the "call" for it via the boolean/var about it and the actual execution of the function in need.

EDIT: I had in mind a fast function, I suppose it might be doable if the function called is very slow (to complete).

Then again, we'd need to deal with thread safety and plain concurrency, so this is all probably wrong.

You could fire a thread to execute a function, but the caller would probably still want to wait for the result. Threading is by definition useful for processes that can be done in an isolated form. Not just any call is suitable to be threaded.

If you define such a process, it will probably be just fine to execute multiple threads at once. I wouldn't see any use of having one separate thread that is just calling functions from a queue. It could have some use in a reporting tool for example. To minimize database load, you could choose to execute only one or a small number of reports at a time. After a report is done, a thread could pick up a new report from a queue.

To implement something like this, I would build (and actually have built) a connection pool and a tread pool. If you'd like to build something like this too, I'd encourage you to search for mutexes (atoms/critical sections) and semaphores.

You are looking at somewhere between fibers and simple event driven programming using libevent, glib, etc. In Java this is possible with Green threads.

You'll get better with threads as you use them (like anything) but the idea is to dispatch to secondary threads processing tasks that can run independently of other tasks. A good exercise to get you going is to write a thread that does some calculation on demand and then returns its result via a callback function.

An example that comes up for me fairly regularly when developing mobile apps is the need to fetch an image from a web server. This is a time-consuming operation and it can fail so I want it to happen on a separate thread. If my app gets the image, great. If it fails, then that's no big deal either.

So let's say the user is running my app and we should display some artwork.

First I display a placeholder image or perhaps a spinner
I create a new thread with some parameters (passed via a struct or similar)
parameters might be the url to lookup and a function to call once I have the image.
the new thread starts and looks up the url. If it fails, it just exits.
if it gets the image and validates that it is correct, it now calls the passed-in callback function to deliver the image to the thread that wants it.
There are lots of ways to deliver data across threads, but you have to be aware of concurrency issues (race conditions, deadlocks) and how they can occur.

In the simplest case, both threads would share a mutex. this type of object helps facilitate synchronization among threads by protecting a data resource. the thread delivering the image would lock the mutex. this gives it exclusive access to a data resource, perhaps an image queue, where it sticks the image. then it unlocks the mutex. Its job is now done so the image-fetcher thread can exit.

In the course of its running, the thread that wants the image needs to check the image queue periodically to see if there is a new image. It locks the mutex, checks the queue and copies out the image if it finds one, then unlocks the mutex.

This is one of the most basic cases for using threads with a shared resource. As you learn more you can discover in addition to mutexes other structures used for signaling threads and for many other types of operations.

A great book for learning more about threads and synchronization in general is Andrew Tanenbaum's Operating Systems Book. It's usually required reading for most Computer Science students and will teach you an enormous amount. Take a look here.