|
|
How is threading different from tasks using shared memory?
The obvious question many ask is: what is the difference between threading
and forks with shared memory. Well, these tables hopefully help see the
difference.
Threading
| Common Memory |
Threads naturally have shared data regions. |
| Locks |
Not inherent. No protection. This is the real power: you only lock
what you want to own. |
| Switching |
Fast. Since the data is inherently shared, the context switches don't
have to flush all the memory management buffers. On other systems (non-linux),
this can be very fast. However, I must point out that the benchmarks done
on Linux vs. NT and others have clearly placed Linux in the context-switching
lead. Private data - No such thing. If you clone() with data and stack
shared, all subsequent memory allocations can be seen by other threads.
I well-behaved program will naturally shadow this, making it a non-issue. |
| SMP |
Threads will ensure 100% tight-coupled SMP. Your program will always
work from platform to platform. |
Forks with Shared Memory
| Common Memory |
Have to be specially created and initialized. |
| Locks |
Somewhat inherent. You have to give/take permission to write to a block.
This is done via "whole blocks"--you can't have one shared memory
block and lock only a piece of it. |
| Switching |
Full context reload. This is bad. Private Data - Inherent. |
| SMP |
May cause problems if not 100% tight-coupled SMP. You can actually
have your program run on a distributed system (via network). From thence,
shared memory calls WILL FAIL, because the tasks will not be talking about
the share memory IDs. On a distributed system you cannot 100% ensure same-memory
processing (your process may migrate to an unused CPU across the net). |
|