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).

[Previous Page]	[First Page]	[Dictionary]	[Email Author]	[Next Page]

---

---