Linux Threads Home Page: How is threading different from tasks using shared memory?
Author: Sean Walton

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]