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.
|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).|
|[Previous Page]||[First Page]||[Dictionary]||[Next Page]|