Linux中thread (light-weighted process) 跟process在實作上幾乎一樣。

最大的差異來自於，thread 會分享 virtual memory address space.

a. 從kernel角度看兩者沒差別，在user看來process是least shared而thread是most sharing.

b. 從實作角度來比較:

創建user process的方法是有三個API: fork, vfork, clone
創建user thread的方法主要是使用thread library: pthread_create
創建kernel thread的方法有兩種API: kernel_thread, kthread_create

而以上這些API還有library function最後都會call到do_fork
而do_fork所做的事就是填task_struct，這邊有一個我覺得很酷的觀念要講一下
          *** 只要填好task_struct就是把該task給創建出來了 !!! *** 
可以知道其實user process, user thread就只是在task_struct的填法不一樣而已。

ref.

[1]http://www.mulix.org/lectures/kernel_workshop_mar_2004/things.pdf

[2]http://stackoverflow.com/questions/807506/threads-vs-processes-in-linux

Linux uses a 1-1 threading model, with (to the kernel) no distinction between processes and threads
-- everything is simply a runnable task. *On Linux, the system call clone clones a task, with a configurable level of sharing, among which are:CLONE_FILES: share the same file descriptor table (instead of creating a copy)
CLONE_PARENT: don't set up a parent-child relationship between the new task and the old
(otherwise, child's getppid() = parent's getpid())
CLONE_VM: share the same memory space (instead of creating a COW copy)
fork() calls clone(least sharing) and pthread_create() calls clone(most sharing). **forking costs a tiny bit more than pthread_createing because of copying tables and creating COW mappings for memory,
but the Linux kernel developers have tried (and succeeded) at minimizing those costs.Switching between tasks, if they share the same memory space and various tables, will be a tiny bit cheaper
than if they aren't shared, because the data may already be loaded in cache. However,
switching tasks is still very fast even if nothing is shared -- this is something else that Linux kernel developers
try to ensure (and succeed at ensuring).In fact, if you are on a multi-processor system, not sharing may actually be a performance boon:
if each task is running on a different processor, synchronizing shared memory is expensive.