nemesis <nam### [at] gmailcom> wrote:
> Aside from embarassingly parallel tasks like raytracing, most apps still are
> essentially single threaded, apart perhaps from another thread for a database
> connection and another for GUI events, no matter how many cores keep idle in
> your new CPUs.  At least the OS can start processes in different ones...

  Actually a surprisingly large number of GUI applications are multithreaded,
by necessity. Basically any GUI application which performs tasks which take
time to complete (be it because the task is very cpu-intensive and takes
time to calculate, or because the program has to wait for something, eg.
data to be downloaded from the internet) have to be multithreaded: One
thread for the task and another for updating the GUI. Such a GUI app *can*
be single-threaded, but then it becomes completely unresponsive while the
task is being performed (even the app's window will not be repainted, and
the app will be listed as "not responding" in the OS's task manager), which
is quite ugly and user-unfriendly.

  Of course what people *usually* mean by "multithreaded" is that the
*task* itself is performed by multiple threads. The 2-thread gui/task
idiom is not usually what is meant by a "multithreaded application",
even though technically speaking it is. (The difference with the gui/task
2-thread idiom and a truly multi-threaded application in the colloquial
sense is that the latter can make use of multiple processors/cores to
perform the task more quickly, while the former doesn't.)

  One industry where multithreading has been all the rage in later years
is the gaming industry. Every major (and even most minor) game engine has
jumped on the multithreading bandwagon with the raising popularity of
multicore CPUs.

  The problem of multithreading in a game engine is quite a difficult one.
One of the major problems is that a typical game engine needs to perform
hundreds and hundreds of small tasks on each frame, and distributing these
tasks to multiple processors efficiently is hard. Just the mutual exclusion
problem is hard because it needs to be as efficient as possible. Using
hundreds of software-based locks is simply not going to cut it because
software locks are heavy. Software locks are ok when you need the locking
just once per second, or even a dozen of times per second, but they start
being a significant overhead when you need to lock hundreds of times per
frame (and your target framerate is at least 60 frames per second).

  This efficient locking problem is not something that can usually be
solved by using a programming language which has inherent multithreading
support. You usually need very specialized lock-free algorithms and
containers, and high-level languages often make developing them difficult.

-- 
                                                          - Warp

Post a reply to this message