Why aren't all applications multithreaded?

[Chaotic42]

I've been thinking about this today, maybe it's because I'm dead f****** tired and sick, but why aren't all applications (games, apps, everything) multithreaded?

Is there a performance hit on single processor systems?

 

[EagleKeeper]

Requires smarts and design issues.
Easy to set up a deadlock if not careful.
Experience required with multi-threaded design and processers

 

[joinT]

Originally posted by: EagleKeeper
Requires smarts and design issues.
Easy to set up a deadlock if not careful.
Experience required with multi-threaded design and processers

Yep, all these things cost $$ & if it's not worth it for the app (ie. even using a single proc it doesn't take up all your cycles) they will generally not bother. But most apps that will benefit the most from it do have it - what kind of app are u talking about that doesn't that you think should ?

 

[Nothinman]

A) Most people don't have SMP boxes.
B) Locking and synchronization between threads is a lot more work.
C) Individual threads deadlocking or just corrupting data because of bad locking is hard to debug.

 

[DaveSimmons]

Like they said, a lot of extra design and debugging work for no real benefit.

For some apps single-threaded is also more intuitive or safer: for example an app that processes data can be safer to use if it doesn't do data processing in one thread while using a second thread to let you edit the data being processed in the first thread. Otherwise wackiness can ensue

 

[Argo]

On single processor system single-threaded app will run faster, sinec there is no overhead of context switching and data locking.

 

[Chaotic42]

Ok, these are the answers that I was looking for

I don't know anything about multithreaded programming, so I was curious. Thanks.

Anyone know of any good books on the subject?

 

[Codewiz]

Originally posted by: Chaotic42
Ok, these are the answers that I was looking for

I don't know anything about multithreaded programming, so I was curious. Thanks.

Anyone know of any good books on the subject?

If you are in college try and take an Operating Systems class. That is where I learned about threading and forks in unix.

 

[Chaotic42]

Originally posted by: Codewiz

Originally posted by: Chaotic42
Ok, these are the answers that I was looking for

I don't know anything about multithreaded programming, so I was curious. Thanks.

Anyone know of any good books on the subject?

If you are in college try and take an Operating Systems class. That is where I learned about threading and forks in unix.

I have the option for one OS class. I'm not too sure if it will cover Unix.

I was thinking of taking

C Programming (for the credit, should be an easy A)
English Comp 1
Physics 1

I work full time, so these will be evening classes. Getting a book might be a better idea.

 

[Nothinman]

On single processor system single-threaded app will run faster, sinec there is no overhead of context switching and data locking.

Depends on how it's setup, like Linux on a UP system all the locks are noops so they take no cycles.

I have the option for one OS class. I'm not too sure if it will cover Unix.

I believe most do becaues it's much easier to get the source to Linux or FreeBSD than it is to Windows.

 

[mjquilly]

Originally posted by: Argo
On single processor system single-threaded app will run faster, sinec there is no overhead of context switching and data locking.

not true, multi-treaded programs can indeed execute faster on a single proc machine; suppose one thread is waiting for i/o while another simple needs some cpu time w/o the need to wait for the other thread....

 

[Argo]

Originally posted by: mjquilly

Originally posted by: Argo
On single processor system single-threaded app will run faster, sinec there is no overhead of context switching and data locking.

not true, multi-treaded programs can indeed execute faster on a single proc machine; suppose one thread is waiting for i/o while another simple needs some cpu time w/o the need to wait for the other thread....

That's an extreme case... Plus, it's going to be VERY difficut (and i highlight the word very) to write something like that. This comes from a person with 2 years of experience...

 

[Heifetz]

A multithreaded app might not be faster...but it would be a lot more functional. Most gui applications are multithreaded, so as to let you invoke a function and still be able to use the gui. If it was single threaded, then everytime you use the gui to invoke a function, the gui would be locked, and you would have to wait for the function to finish before you would be able to work with the gui again. How would you like it if your os was only a single threaded app? Web Browsers are all multithreaded apps.

Also, many many apps use different threads when accessing the I/O or when dealing with network access. One of the main reasons of how multithreading came into being is the fact that an app can use a different thread to deal with I/O while letting another thread use the CPU.

Heifetz

 

[manly]

Originally posted by: Argo

Originally posted by: mjquilly

Originally posted by: Argo
On single processor system single-threaded app will run faster, sinec there is no overhead of context switching and data locking.

not true, multi-treaded programs can indeed execute faster on a single proc machine; suppose one thread is waiting for i/o while another simple needs some cpu time w/o the need to wait for the other thread....

That's an extreme case... Plus, it's going to be VERY difficut (and i highlight the word very) to write something like that. This comes from a person with 2 years of experience...

Humpph, there's nothing extreme about it at all, as Heifetz explained.

Also, regarding your original comment, an essential property of multithreading is actually the lack of a full processor context switch. There is of course a switch cost but it's relatively inexpensive.

Strike two.

You are correct that correct multithreaded programming is usually difficult.

 

[KillerCow]

Anyone know of any good books on the subject?

CS 342: Control Structures
Course Notes
Control Flow Book

The course notes were OK... I never looked at the book.

On single processor system single-threaded app will run faster, sinec there is no overhead of context switching and data locking.

Blocking guy, blocking. Whenever there is IO the process stalls and cycles are wasted.

The last app that I made for myself loaded a bunch of XML and CSV files during the initialization stage and put them into Maps. The first version read each file, one after the other. The next revision had worker tasks that would each read a single file; the workers were launched in parallel. There was about 5-10 megs total in these files and the concurrent version was noticably faster.

In most cases, if you think about tasks instead of steps, you can find where to add concurrency. Imagine that you are a manager and you have n workers working for you... how would you divide the work among them such that they will need to communicate with each other in a minimal amount (the single threaded model only uses one worker... no communication problems there!). That said, deadlock and livelock are dangerous if you try to parralelize to many independent things.

 

[mjquilly]

Originally posted by: Argo

Originally posted by: mjquilly

Originally posted by: Argo
On single processor system single-threaded app will run faster, sinec there is no overhead of context switching and data locking.

not true, multi-treaded programs can indeed execute faster on a single proc machine; suppose one thread is waiting for i/o while another simple needs some cpu time w/o the need to wait for the other thread....

That's an extreme case... Plus, it's going to be VERY difficut (and i highlight the word very) to write something like that. This comes from a person with 2 years of experience...

Programming for performance isn't supposed to be easy, but I wouldn't necessarily say VERY difficult. oh yeah, and this comes from a person with 6 years of experience.

 

[CTho9305]

NOPing out code doesn't make it disappear... the CPU still spends some time on it (unless you jump over it)

 

[Nothinman]

NOPing out code doesn't make it disappear... the CPU still spends some time on it (unless you jump over it)

If you're referring to what I said, I phrased that poorly. The spinlock macros are #ifdef'd so that if a UP kernel is being compiled they don't do anything and the compiler optimizes them out.

 

[Chaotic42]

Thanks KillerCow.

This is all very interesting.

 

[HigherGround]

If you're referring to what I said, I phrased that poorly. The spinlock macros are #ifdef'd so that if a UP kernel is being compiled they don't do anything and the compiler optimizes them out.

you meant preprocessor. On top of that thread synchronization primitives have nothing to do with kernel being MP or UP. If you are locking/unlocking a mutex in an MT application, it's going to cost you CPU cycles one way or the other.