linux雙向通信
『壹』 linux共享內存的優點缺點
共享內存塊提供了在任意數量的進程之間進行高效雙向通信的機制。每個使用者都可以讀取寫入數據，但是所有程序之間必須達成並遵守一定的協議，以防止諸如在讀取信息之前覆寫內存空間等競爭狀態的出現。不幸的是，Linux無法嚴格保證提供對共享內存塊的獨占訪問，甚至是在您通過使用IPC_PRIVATE創建新的共享內存塊的時候也不能保證訪問的獨占性。 同時，多個使用共享內存塊的進程之間必須協調使用同一個鍵值。
『貳』 LINUX設備驅動程序如何與硬體通信
LINUX設備驅動程序是怎麼樣和硬體通信的?下面將由我帶大家來解答這個疑問吧，希望對大家有所收獲!
LINUX設備驅動程序與硬體設備之間的通信
設備驅動程序是軟體概念和硬體電路之間的一個抽象層，因此兩方面都要討論。到目前為止，我們已經討論詳細討論了軟體概念上的一些細節，現在討論另一方面，介紹驅動程序在Linux上如何在保持可移植性的前提下訪問I/O埠和I/O內存。
我們在需要示例的場合會使用簡單的數字I/O埠來講解I/O指令，並使用普通的幀緩沖區顯存來講解內存映射I/O。
I/O埠和I/O內存
計算機對每種外設都是通過讀寫它的寄存器進行控制的。大部分外設都有幾個寄存器，不管是在內存地址空間還是在I/O地址空間，這些寄存器的訪問地址都是連續的。
I/O埠就是I/O埠，設備會把寄存器映射到I/O埠，不管處理器是否具有獨立的I/O埠地址空間。即使沒有在訪問外設時也要模擬成讀寫I/O埠。
I/O內存是設備把寄存器映射到某個內存地址區段(如PCI設備)。這種I/O內存通常是首先方案，它不需要特殊的處理器指令，而且CPU核心訪問內存更有效率。
I/O寄存器和常規內存
盡管硬體寄存器和內存非常相似，但程序員在訪問I/O寄存器的時候必須注意避免由於CPU或編譯器不恰當的優化而改變預期的I/O動作。
I/O寄存器和RAM最主要的區別就是I/O操作具有邊際效應，而內存操作則沒有：由於內存沒有邊際效應，所以可以用多種 方法 進行優化，如使用高速緩存保存數值、重新排序讀/寫指令等。
編譯器能夠將數值緩存在CPU寄存器中而不寫入內存，即使儲存數據，讀寫操作也都能在高速緩存中進行而不用訪問物理RAM。無論是在編譯器一級或是硬體一級，指令的重新排序都有可能發生：一個指令序列如果以不同於程序文本中的次序運行常常能執行得更快。
在對常規內存進行這些優化的時候，優化過程是透明的，而且效果良好，但是對I/O操作來說這些優化很可能造成致命的錯誤，這是因為受到邊際效應的干擾，而這卻是驅動程序訪問I/O寄存器的主要目的。處理器無法預料某些 其它 進程(在另一個處理器上運行，或在在某個I/O控制器中發生的操作)是否會依賴於內存訪問的順序。編譯器或CPU可能會自作聰明地重新排序所要求的操作，結果會發生奇怪的錯誤，並且很難調度。因此，驅動程序必須確保不使用高速緩沖，並且在訪問寄存器時不發生讀或寫指令的重新排序。
由硬體自身引起的問題很解決：只要把底層硬體配置成(可以是自動的或是由Linux初始化代碼完成)在訪問I/O區域(不管是內存還是埠)時禁止硬體緩存即可。
由編譯器優化和硬體重新排序引起的問題的解決辦法是：對硬體(或其他處理器)必須以特定順序的操作之間設置內存屏障(memory barrier)。Linux提供了4個宏來解決所有可能的排序問題：
#include <linux/kernel.h>
void barrier(void)
這個函數通知編譯器插入一個內存屏障，但對硬體沒有影響。編譯後的代碼會把當前CPU寄存器中的所有修改過的數值保存到內存中，需要這些數據的時候再重新讀出來。對barrier的調用可避免在屏障前後的編譯器優化，但硬體完成自己的重新排序。
#include <asm/system.h>
void rmb(void);
void read_barrier_depends(void);
void wmb(void);
void mb(void);
這些函數在已編譯的指令流中插入硬體內存屏障;具體實現方法是平台相關的。rmb(讀內存屏障)保證了屏障之前的讀操作一定會在後來的讀操作之前完成。wmb保證寫操作不會亂序，mb指令保證了兩者都不會。這些函數都是barrier的超集。
void smp_rmb(void);
void smp_read_barrier_depends(void);
void smp_wmb(void);
void smp_mb(void);
上述屏障宏版本也插入硬體屏障，但僅僅在內核針對SMP系統編譯時有效;在單處理器系統上，它們均會被擴展為上面那些簡單的屏障調用。
設備驅動程序中使用內存屏障的典型形式如下：
writel(dev->registers.addr, io_destination_address);
writel(dev->registers.size, io_size);
writel(dev->registers.operation, DEV_READ);
wmb();
writel(dev->registers.control, DEV_GO);
在這個例子中，最重要的是要確保控制某種特定操作的所有設備寄存器一定要在操作開始之前已被正確設置。其中的內存屏障會強制寫操作以要求的順序完成。
因為內存屏障會影響系統性能，所以應該只用於真正需要的地方。不同類型的內存屏障對性能的影響也不盡相同，所以最好盡可能使用最符合需要的特定類型。
值得注意的是，大多數處理同步的內核原語，如自旋鎖和atomic_t操作，也能作為內存屏障使用。同時還需要注意，某些外設匯流排(比如PCI匯流排)存在自身的高速緩存問題，我們將在後面的章節中討論相關問題。
在某些體系架構上，允許把賦值語句和內存屏障進行合並以提高效率。內核提供了幾個執行這種合並的宏，在默認情況下，這些宏的定義如下：
#define set_mb(var, value) do {var = value; mb();} while 0
#define set_wmb(var, value) do {var = value; wmb();} while 0
#define set_rmb(var, value) do {var = value; rmb();} while 0
在適當的地方，<asm/system.h>中定義的這些宏可以利用體系架構特有的指令更快的完成任務。注意只有小部分體系架構定義了set_rmb宏。
使用I/O埠
I/O埠是驅動程序與許多設備之間的通信方式——至少在部分時間是這樣。本節講解了使用I/O埠的不同函數，另外也涉及到一些可移植性問題。
I/O埠分配
下面我們提供了一個注冊的介面，它允允許驅動程序聲明自己需要操作的埠：
#include <linux/ioport.h>
struct resource *request_region(unsigned long first, unsigned long n, const char *name);
它告訴內核，我們要使用起始於first的n個埠。name是設備的名稱。如果分配成功返回非NULL，如果失敗返回NULL。
所有分配的埠可從/proc/ioports中找到。如果我們無法分配到我們要的埠集合，則可以查看這個文件哪個驅動程序已經分配了這些埠。
如果不再使用這些埠，則用下面函數返回這些埠給系統：
void release_region(unsigned long start, unsigned long n);
下面函數允許驅動程序檢查給定的I/O埠是否可用：
int check_region(unsigned long first, unsigned long n);//不可用返回負的錯誤代碼
我們不贊成用這個函數，因為它返回成功並不能確保分配能夠成功，因為檢查和其後的分配並不是原子操作。我們應該始終使用request_region，因為這個函數執行了必要的鎖定，以確保分配過程以安全原子的方式完成。
操作I/O埠
當驅動程序請求了需要使用的I/O埠范圍後，必須讀取和/或寫入這些埠。為此，大多數硬體都會把8位、16位、32位區分開來。它們不能像訪問系統內存那樣混淆使用。
因此，C語言程序必須調用不同的函數訪問大小不同的埠。那些只支持映射的I/O寄存器的計算機體系架構通過把I/O埠地址重新映射到內存地址來偽裝埠I/O，並且為了易於移植，內核對驅動程序隱藏了這些細節。Linux內核頭文件中(在與體系架構相關的頭文件<asm/io.h>中)定義了如下一些訪問I/O埠的內聯函數：
unsigned inb(unsigned port);
void outb(unsigned char byte, unsigned port);
位元組讀寫埠。
unsigned inw(unsigned port);
void outw(unsigned short word, unsigned port);
訪問16位埠
unsigned inl(unsigned port);
void outl(unsigned longword, unsigned port);
訪問32位埠
在用戶空間訪問I/O埠
上面這些函數主要是提供給設備驅動程序使用的，但它們也可以用戶空間使用，至少在PC類計算機上可以使用。GNU的C庫在<sys/io.h>中定義了這些函數。如果要要用戶空間使用inb及相關函數，則必須滿足正下面這些條件：
編譯程序時必須帶有-O選項來強制內聯函數的展開。
必須用ioperm(獲取單個埠的許可權)或iopl(獲取整個I/O空間)系統調用來獲取對埠進行I/O操作的許可權。這兩個函數都是x86平台特有的。
必須以root身份運行該程序才能調用ioperm或iopl。或者進程的祖先進程之一已經以root身份獲取對埠的訪問。
如果宿主平台沒有以上兩個系統調用，則用戶空間程序仍然可以使用/dev/port設備文件訪問I/O埠。不過要注意，該設備文件的含義與平台密切相關，並且除PC平台以處，它幾乎沒有什麼用處。
串操作
以上的I/O操作都是一次傳輸一個數據，作為補充，有些處理器實現了一次傳輸一個數據序列的特殊指令，序列中的數據單位可以是位元組、字、雙字。這些指令稱為串操作指令，它們執行這些任務時比一個C語言編寫的循環語句快得多。下面列出的宏實現了串I/O：
void insb(unsigned port, void *addr, unsigned long count);
void outsb(unsigned port, void *addr, unsigned long count);從內存addr開始連續讀/寫count數目的位元組。只對單一埠port讀取或寫入數據
void insw(unsigned port, void *addr, unsigned long count);
void outsw(unsigned port, void *addr, unsigned long count);對一個16位埠讀寫16位數據
void insl(unsigned port, void *addr, unsigned long count);
void outsl(unsigned port, void *addr, unsigned long count);對一個32位埠讀寫32位數據
在使用串I/O操作函數時，需要銘記的是：它們直接將位元組流從埠中讀取或寫入。因此，當埠和主機系統具有不同的位元組序時，將導致不可預期的結果。使用inw讀取埠將在必要時交換位元組，以便確保讀入的值匹配於主機的位元組序。然而，串函數不會完成這種交換。
暫停式I/O
在處理器試圖從匯流排上快速傳輸數據時，某些平台(特別是i386)就會出現問題。當處理器時鍾比外設時鍾(如ISA)快時就會出現問題，並且在設備板上特別慢時表現出來。為了防止出現丟失數據的情況，可以使用暫停式的I/O函數來取代通常的I/O函數，這些暫停式的I/O函數很像前面介紹的那些I/O函數，不同之處是它們的名字用_p結尾，如inb_p、outb_p等等。在linux支持的大多數平台上都定義了這些函數，不過它們常常擴展為非暫停式I/O同樣的代碼，因為如果不使用過時的外設匯流排就不需要額外的暫停。
平台相關性
I/O指令是與處理器密切相關的。因為它們的工作涉及到處理器移入移出數據的細節，所以隱藏平台間的差異非常困難。因此，大部分與I/O埠相關的源代碼都與平台相關。
回顧前面函數列表可以看到有一處不兼容的地方，即數據類型。函數的參數根據各平台體系架構上的不同要相應地使用不同的數據類型。例如，port參數在x86平台上(處理器只支持64KB的I/O空間)上定義為unsigned short，但在其他平台上定義為unsigned long，在這些平台上，埠是與內存在同一地址空間內的一些特定區域。
感興趣的讀者可以從io.h文件獲得更多信息，除了本章介紹的函數，一些與體系架構相關的函數有時也由該文件定義。
值得注意的是，x86家族之外的處理器都不為埠提供獨立的地址空間。
I/O操作在各個平台上執行的細節在對應平台的編程手冊中有詳細的敘述;也可以從web上下載這些手冊的PDF文件。
I/O埠示例
演示設備驅動程序的埠I/O的示例代碼運行於通用的數字I/O埠上，這種埠在大多數計算機平台上都能找到。
數字I/O埠最常見的一種形式是一個位元組寬度的I/O區域，它或者映射到內存，或者映射到埠。當把數字寫入到輸出區域時，輸出引腳上的電平信號隨著寫入的各位而發生相應變化。從輸入區域讀取到的數據則是輸入引腳各位當前的邏輯電平值。
這類I/O埠的具體實現和軟體介面是因系統而異的。大多數情況下，I/O引腳由兩個I/O區域控制的：一個區域中可以選擇用於輸入和輸出的引腳，另一個區域中可以讀寫實際的邏輯電平。不過有時情況簡單些，每個位不是輸入就是輸出(不過這種情況下就不能稱為“通用I/O"了);在所有個人計算機上都能找到的並口就是這樣的非通用的I/O埠。
並口簡介
並口的最小配置由3個8位埠組成。第一個埠是一個雙向的數據寄存器，它直接連接到物理連接器的2~9號引腳上。第二個埠是一個只讀的狀態寄存器;當並口連接列印機時，該寄存器 報告 列印機狀態，如是否是線、缺紙、正忙等等。第三個埠是一個只用於輸出的控制寄存器，它的作用之一是控制是否啟用中斷。
如下所示：並口的引腳
示例驅動程序
while(count--) {
outb(*(ptr++), port);
wmb();
}
使用I/O內存
除了x86上普遍使的I/O埠之外，和設備通信的另一種主要機制是通過使用映射到內存的寄存器或設備內存，這兩種都稱為I/O內存，因為寄存器和內存的差別對軟體是透明的。
I/O內存僅僅是類似RAM的一個區域，在那裡處理器可以通過匯流排訪問設備。這種內存有很多用途，比如存放視頻數據或乙太網數據包，也可以用來實現類似I/O埠的設備寄存器(也就是說，對它們的讀寫也存在邊際效應)。
根據計算機平台和所使用匯流排的不同，i/o內存可能是，也可能不是通過頁表訪問的。如果訪問是經由頁表進行的，內核必須首先安排物理地址使其對設備驅動程序可見(這通常意味著在進行任何I/O之前必須先調用ioremap)。如果訪問無需頁表，那麼I/O內存區域就非常類似於I/O埠，可以使用適當形式的函數讀取它們。
不管訪問I/O內存是否需要調用ioremap，都不鼓勵直接使用指向I/O內存的指針。相反使用包裝函數訪問I/O內存，這一方面在所有平台上都是安全的，另一方面，在可以直接對指針指向的內存區域執行操作的時候，這些函數是經過優化的。並且直接使用指針會影響程序的可移植性。
I/O內存分配和映射
在使用之前，必須首先分配I/O區域。分配內存區域的介面如下(在<linux/ioport.h>中定義)：
struct resource *request_mem_region(unsigned long start, unsigned long len, char *name);
該函數從start開始分配len位元組長的內存區域。如果成功返回非NULL，否則返回NULL值。所有的I/O內存分配情況可從/proc/iomem得到。
不再使用已分配的內存區域時，使用如下介面釋放：
void release_mem_region(unsigned long start, unsigned long len);
下面函數用來檢查給定的I/O內存區域是否可用的老函數：
int check_mem_region(unsigned long start, unsigned long len);//這個函數和check_region一樣不安全，應避免使用
分配內存之後我們還必須確保該I/O內存對內存而言是可訪問的。獲取I/O內存並不意味著可引用對應的指針;在許多系統上，I/O內存根本不能通過這種方式直接訪問。因此，我們必須由ioremap函數建立映射，ioremap專用於為I/O內存區域分配虛擬地址。
我們根據以下定義來調用ioremap函數：
#include <asm/io.h>
void *ioremap(unsigned long phys_addr, unsigned long size);
void *ioremap_nocache(unsigned long phys_addr, unsigned long size);在大多數計算機平台上，該函數和ioremap相同：當所有I/O內存已屬於非緩存地址時，就沒有必要實現ioremap的獨立的，非緩沖版本。
void iounmap(void *addr);
記住，由ioremap返回的地址不應該直接引用，而應該使用內核提供的accessor函數。
訪問I/O內存
在某些平台上我們可以將ioremap的返回值直接當作指針使用。但是，這種使用不具有可移植性，訪問I/O內存的正確方法是通過一組專用於些目的的函數(在<asm/io.h>中定義)。
從I/O內存中讀取，可使用以下函數之一：
unsigned int ioread8(void *addr);
unsigned int ioread16(void *addr);
unsigned int ioread32(void *addr);
其中，addr是從ioremap獲得的地址(可能包含一個整數偏移量);返回值是從給定I/O內存讀取到的值。
寫入I/O內存的函數如下：
void iowrite8(u8 value, void *addr);
void iowrite16(u16 value, void *addr);
void iowrite32(u32 value, void *addr);
如果必須在給定的I/O內存地址處讀/寫一系列值，則可使用上述函數的重復版本：
void ioread8_rep(void *addr, void *buf, unsigned long count);
void ioread16_rep(void *addr, void *buf, unsigned long count);
void ioread32_rep(void *addr, void *buf, unsigned long count);
void iowrite8_rep(void *addr, const void *buf, unsigned long count);
void iowrite16_rep(void *addr, const void *buf, unsigned long count);
void iowrite32_rep(void *addr, const void *buf, unsigned long count);
上述函數從給定的buf向給定的addr讀取或寫入count個值。count以被寫入數據的大小為單位。
上面函數均在給定的addr處執行所有的I/O操作，如果我們要在一塊I/O內存上執行操作，則可以使用下面的函數：
void memset_io(void *addr, u8 value, unsigned int count);
void memcpy_fromio(void *dest, void *source, unsigned int count);
void memcpy_toio(void *dest, void *source, unsigned int count);
上述函數和C函數庫的對應函數功能一致。
像I/O內存一樣使用I/O埠
某些硬體具有一種有趣的特性：某些版本使用I/O埠，而其他版本則使用I/O內存。導出給處理器的寄存器在兩種情況下都是一樣的，但訪問方法卻不同。為了讓處理這類硬體的驅動程序更加易於編寫，也為了最小化I/O埠和I/O內存訪問這間的表面區別，2.6內核引入了ioport_map函數：
void *ioport_map(unsigned long port, unsigned int count);
該函數重新映射count個I/O埠，使其看起來像I/O內存。此後，驅動程序可在該函數返回的地址上使用ioread8及其相關函數，這樣就不必理會I/O埠和I/O內存之間的區別了。
當不需要這種映射時使用下面函數一撤消：
void ioport_unmap(void *addr);
這些函數使得I/O埠看起來像內存。但需要注意的是，在重新映射之前，我們必須通過request_region來分配這些I/O埠。
為I/O內存重用short
前面介紹的short示例模塊訪問的是I/O埠，它也可以訪問I/O內存。為此必須在載入時通知它使用I/O內存，另外還要修改base地址以使其指向I/O區域。
下例是在MIPS開發板上點亮調試用的LED：
mips.root# ./short_load use_mem=1 base = 0xb7ffffc0
mips.root# echo -n 7 > /dev/short0
下面代碼是short寫入內存區域時使用的循環：
while(count--) {
iowrite8(*ptr++, address);
wmb();
}
1MB地址空間之下的ISA內存
最廣為人知的I/O內存區之一就是個人計算機上的ISA內存段。它的內存范圍在64KB(0xA0000)到1MB(0x100000)之間，因此它正好出現在常規系統RAM的中間。這種地址看上去有點奇怪，因為這個設計決策是20世紀80年代早期作出的，在當時看來沒有人會用到640KB以上的內存。
『叄』 Linux 進程間套接字通信（Socket)基礎知識
姓名：羅學元 學號：21181214375 學院：廣州研究院
【嵌牛導讀】Linux進程間套接字通信基礎
【嵌牛鼻子】Linux 進程間套接字及通信介紹
【嵌牛提問】Linux進程間套接字包含哪些內容，如何實現通信
一、套接字（Socket）通信原理
套接字通信允許互聯的位於不同計算機上的進程之間實現通信功能。
二、套接字的屬性
套接字的特性由3個屬性確定，它們分別是：域、類型和協議。
1. 套接字的域
它指定套接字通信中使用的網路介質，最常見的套接字域是AF_INET，它指的是Internet網路。當客戶使用套接字進行跨網路的連接時，它就需要用到伺服器計算機的IP地址和埠來指定一台聯網機器上的某個特定服務，所以在使用socket作為通信的終點，伺服器應用程序必須在開始通信之前綁定一個埠，伺服器在指定的埠等待客戶的連接。
另一個域AF_UNIX表示UNIX文件系統，就是文件輸入/輸出，它的地址就是文件名。
2. 套接字類型
網際網路提供了兩種通信機制：流（stream）和數據報（datagram），因而套接字的類型也就分為流套接字和數據報套接字。我們主要看流套接字。
流套接字由類型SOCK_STREAM指定，它們是在AF_INET域中通過TCP/IP連接實現，同時也是AF_UNIX中常用的套接字類型。
流套接字提供的是一個有序、可靠、雙向位元組流的連接，因此發送的數據可以確保不會丟失、重復或亂序到達，而且它還有一定的出錯後重新發送的機制。
與流套接字相對的是由類型SOCK_DGRAM指定的數據報套接字，它不需要建立連接和維持一個連接，它們在AF_INET中通常是通過UDP/IP實現的。它對可以發送的數據的長度有限制，數據報作為一個單獨的網路消息被傳輸，它可能丟失、復制或錯亂到達，UDP不是一個可靠的協議，但是它的速度比較高，因為它並不需要總是要建立和維持一個連接。
3.套接字協議
只要底層的傳輸機制允許不止一個協議來提供要求的套接字類型，我們就可以為套接字選擇一個特定的協議。通常只需要使用默認值。
三、套接字地址
每個套接字都有其自己的地址格式，對於AF_UNIX域套接字來說，它的地址由結構sockaddr_un來描述，該結構定義在頭文件
struct sockaddr_un{
sa_family_t sun_family; //AF_UNIX，它是一個短整型
char sum_path[]; //路徑名
};
對於AF_INET域套接字來說，它的地址結構由sockaddr_in來描述，它至少包括以下幾個成員：
struct sockaddr_in{
short int sin_family; //AN_INET
unsigned short int sin_port; //埠號
struct in_addr sin_addr; //IP地址
}
而in_addr被定義為：
struct in_addr{
unsigned long int s_addr;
}
四、基於流套接字的客戶/伺服器的工作流程
使用socket進行進程通信的進程採用的客戶/伺服器系統是如何工作的呢？
1.伺服器端
首先，伺服器應用程序用系統調用socket來創建一個套接字，它是系統分配給該伺服器進程的類似文件描述符的資源，它不能與其他的進程共享。
接下來，伺服器進程會給套接字起個名字，我們使用系統調用bind來給套接字命名。然後伺服器進程就開始等待客戶連接到這個套接字。
然後，系統調用listen來創建一個隊列，並將其用於存放來自客戶的進入連接。
最後，伺服器通過系統調用accept來接受客戶的連接。它會創建一個與原有的命名套接不同的新套接字，這個套接字只用於與這個特定客戶端進行通信，而命名套接字（即原先的套接字）則被保留下來繼續處理來自其他客戶的連接。
2.客戶端
基於socket的客戶端比伺服器端簡單。同樣，客戶應用程序首先調用socket來創建一個未命名的套接字，然後講伺服器的命名套接字作為一個地址來調用connect與伺服器建立連接。
一旦連接建立，我們就可以像使用底層的文件描述符那樣用套接字來實現雙向數據的通信。
『肆』 如何看懂《Linux多線程服務端編程
一：進程和線程
每個進程有自己獨立的地址空間。「在同一個進程」還是「不在同一個進程」是系統功能劃分的重要決策點。《Erlang程序設計》[ERL]把進程比喻為人：
每個人有自己的記憶（內存），人與人通過談話（消息傳遞）來交流，談話既可以是面談（同一台伺服器），也可以在電話里談（不同的伺服器，有網路通信）。面談和電話談的區別在於，面談可以立即知道對方是否死了（crash,SIGCHLD），而電話談只能通過周期性的心跳來判斷對方是否還活著。
有了這些比喻，設計分布式系統時可以採取「角色扮演」，團隊里的幾個人各自扮演一個進程，人的角色由進程的代碼決定（管登錄的、管消息分發的、管買賣的等等）。每個人有自己的記憶，但不知道別人的記憶，要想知道別人的看法，只能通過交談（暫不考慮共享內存這種IPC）。然後就可以思考：
·容錯：萬一有人突然死了
·擴容：新人中途加進來
·負載均衡：把甲的活兒挪給乙做
·退休：甲要修復bug，先別派新任務，等他做完手上的事情就把他重啟
等等各種場景，十分便利。
線程的特點是共享地址空間，從而可以高效地共享數據。一台機器上的多個進程能高效地共享代碼段(操作系統可以映射為同樣的物理內存)，但不能共享數據。如果多個進程大量共享內存，等於是把多進程程序當成多線程來寫，掩耳盜鈴。
「多線程」的價值，我認為是為了更好地發揮多核處理器(multi-cores)的效能。在單核時代，多線程沒有多大價值（個人想法：如果要完成的任務是CPU密集型的，那多線程沒有優勢，甚至因為線程切換的開銷，多線程反而更慢；如果要完成的任務既有CPU計算，又有磁碟或網路IO，則使用多線程的好處是，當某個線程因為IO而阻塞時，OS可以調度其他線程執行，雖然效率確實要比任務的順序執行效率要高，然而，這種類型的任務，可以通過單線程的」non-blocking IO+IO multiplexing」的模型（事件驅動）來提高效率，採用多線程的方式，帶來的可能僅僅是編程上的簡單而已）。Alan Cox說過：」A computer is a state machine.Threads are for people who can』t program state machines.」（計算機是一台狀態機。線程是給那些不能編寫狀態機程序的人准備的）如果只有一塊CPU、一個執行單元，那麼確實如Alan Cox所說，按狀態機的思路去寫程序是最高效的。
二：單線程伺服器的常用編程模型
據我了解，在高性能的網路程序中，使用得最為廣泛的恐怕要數」non-blocking IO + IO multiplexing」這種模型，即Reactor模式。
在」non-blocking IO + IO multiplexing」這種模型中，程序的基本結構是一個事件循環（event loop），以事件驅動（event-driven）和事件回調的方式實現業務邏輯：
[cpp] view plain
//代碼僅為示意，沒有完整考慮各種情況
while(!done)
{
int timeout_ms = max(1000, getNextTimedCallback());
int retval = poll(fds, nfds, timeout_ms);
if (retval<0){
處理錯誤，回調用戶的error handler
}else{
處理到期的timers,回調用戶的timer handler
if(retval>0){
處理IO事件，回調用戶的IO event handler
}
}
}
這里select(2)/poll(2)有伸縮性方面的不足（描述符過多時，效率較低），Linux下可替換為epoll(4)，其他操作系統也有對應的高性能替代品。
Reactor模型的優點很明顯，編程不難，效率也不錯。不僅可以用於讀寫socket，連接的建立(connect(2)/accept(2))，甚至DNS解析都可以用非阻塞方式進行，以提高並發度和吞吐量(throughput)，對於IO密集的應用是個不錯的選擇。lighttpd就是這樣，它內部的fdevent結構十分精妙，值得學習。
基於事件驅動的編程模型也有其本質的缺點，它要求事件回調函數必須是非阻塞的。對於涉及網路IO的請求響應式協議，它容易割裂業務邏輯，使其散布於多個回調函數之中，相對不容易理解和維護。
三：多線程伺服器的常用編程模型
大概有這么幾種：
a：每個請求創建一個線程，使用阻塞式IO操作。在Java 1.4引人NIO之前，這是Java網路編程的推薦做法。可惜伸縮性不佳（請求太多時，操作系統創建不了這許多線程）。
b：使用線程池，同樣使用阻塞式IO操作。與第1種相比，這是提高性能的措施。
c：使用non-blocking IO + IO multiplexing。即Java NIO的方式。
d：Leader/Follower等高級模式。
在默認情況下，我會使用第3種，即non-blocking IO + one loop per thread模式來編寫多線程C++網路服務程序。
1：one loop per thread
此種模型下，程序里的每個IO線程有一個event loop，用於處理讀寫和定時事件（無論周期性的還是單次的）。代碼框架跟「單線程伺服器的常用編程模型」一節中的一樣。
libev的作者說：
One loop per thread is usually a good model. Doing this is almost never wrong, some times a better-performance model exists, but it is always a good start.
這種方式的好處是：
a：線程數目基本固定，可以在程序啟動的時候設置，不會頻繁創建與銷毀。
b：可以很方便地在線程間調配負載。
c：IO事件發生的線程是固定的，同一個TCP連接不必考慮事件並發。
Event loop代表了線程的主循環，需要讓哪個線程幹活，就把timer或IO channel（如TCP連接）注冊到哪個線程的loop里即可：對實時性有要求的connection可以單獨用一個線程；數據量大的connection可以獨佔一個線程，並把數據處理任務分攤到另幾個計算線程中（用線程池）；其他次要的輔助性connections可以共享一個線程。
比如，在dbproxy中，一個線程用於專門處理客戶端發來的管理命令；一個線程用於處理客戶端發來的MySQL命令，而與後端資料庫通信執行該命令時，是將該任務分配給所有事件線程處理的。
對於non-trivial（有一定規模）的服務端程序，一般會採用non-blocking IO + IO multiplexing，每個connection/acceptor都會注冊到某個event loop上，程序里有多個event loop，每個線程至多有一個event loop。
多線程程序對event loop提出了更高的要求，那就是「線程安全」。要允許一個線程往別的線程的loop里塞東西，這個loop必須得是線程安全的。
在dbproxy中，線程向其他線程分發任務，是通過管道和隊列實現的。比如主線程accept到連接後，將表示該連接的結構放入隊列，並向管道中寫入一個位元組。計算線程在自己的event loop中注冊管道的讀事件，一旦有數據可讀，就嘗試從隊列中取任務。
2：線程池
不過，對於沒有IO而光有計算任務的線程，使用event loop有點浪費。可以使用一種補充方案，即用blocking queue實現的任務隊列：
[cpp] view plain
typedef boost::function<void()>Functor;
BlockingQueue<Functor> taskQueue; //線程安全的全局阻塞隊列
//計算線程
void workerThread()
{
while (running) //running變數是個全局標志
{
Functor task = taskQueue.take(); //this blocks
task(); //在產品代碼中需要考慮異常處理
}
}
// 創建容量（並發數）為N的線程池
int N = num_of_computing_threads;
for (int i = 0; i < N; ++i)
{
create_thread(&workerThread); //啟動線程
}
//向任務隊列中追加任務
Foo foo; //Foo有calc()成員函數
boost::function<void()> task = boost::bind(&Foo::calc，&foo);
taskQueue.post(task);
除了任務隊列，還可以用BlockingQueue<T>實現數據的生產者消費者隊列，即T是數據類型而非函數對象，queue的消費者從中拿到數據進行處理。其實本質上是一樣的。
3：總結
總結而言，我推薦的C++多線程服務端編程模式為：one (event) loop per thread + thread pool：
event loop用作IO multiplexing，配合non-blockingIO和定時器；
thread pool用來做計算，具體可以是任務隊列或生產者消費者隊列。
以這種方式寫伺服器程序，需要一個優質的基於Reactor模式的網路庫來支撐，muo正是這樣的網路庫。比如dbproxy使用的是libevent。
程序里具體用幾個loop、線程池的大小等參數需要根據應用來設定，基本的原則是「阻抗匹配」（解釋見下），使得CPU和IO都能高效地運作。所謂阻抗匹配原則：
如果池中線程在執行任務時，密集計算所佔的時間比重為 P (0 < P <= 1)，而系統一共有 C 個 CPU，為了讓這 C 個 CPU 跑滿而又不過載，線程池大小的經驗公式 T = C/P。（T 是個 hint，考慮到 P 值的估計不是很准確，T 的最佳值可以上下浮動 50%）
以後我再講這個經驗公式是怎麼來的，先驗證邊界條件的正確性。
假設 C = 8，P = 1.0，線程池的任務完全是密集計算，那麼T = 8。只要 8 個活動線程就能讓 8 個 CPU 飽和，再多也沒用，因為 CPU 資源已經耗光了。
假設 C = 8，P = 0.5，線程池的任務有一半是計算，有一半等在 IO 上，那麼T = 16。考慮操作系統能靈活合理地調度 sleeping/writing/running 線程，那麼大概 16 個「50%繁忙的線程」能讓 8 個 CPU 忙個不停。啟動更多的線程並不能提高吞吐量，反而因為增加上下文切換的開銷而降低性能。
如果 P < 0.2，這個公式就不適用了，T 可以取一個固定值，比如 5*C。
另外，公式里的 C 不一定是 CPU 總數，可以是「分配給這項任務的 CPU 數目」，比如在 8 核機器上分出 4 個核來做一項任務，那麼 C=4。
四：進程間通信只用TCP
Linux下進程間通信的方式有：匿名管道(pipe)、具名管道(FIFO)、POSIX消息隊列、共享內存、信號(signals)，以及Socket。同步原語有互斥器(mutex)、條件變數(condition variable)、讀寫鎖(reader-writer lock)、文件鎖(record locking)、信號量(semaphore)等等。
進程間通信我首選Sockets（主要指TCP，我沒有用過UDP，也不考慮Unix domain協議）。其好處在於：
可以跨主機，具有伸縮性。反正都是多進程了，如果一台機器的處理能力不夠，很自然地就能用多台機器來處理。把進程分散到同一區域網的多台機器上，程序改改host:port配置就能繼續用；
TCP sockets和pipe都是操作文件描述符，用來收發位元組流，都可以read/write/fcntl/select/poll等。不同的是，TCP是雙向的，Linux的pipe是單向的，進程間雙向通信還得開兩個文件描述符，不方便；而且進程要有父子關系才能用pipe，這些都限制了pipe的使用；
TCP port由一個進程獨占，且進程退出時操作系統會自動回收文件描述符。因此即使程序意外退出，也不會給系統留下垃圾，程序重啟之後能比較容易地恢復，而不需要重啟操作系統（用跨進程的mutex就有這個風險）；而且，port是獨占的，可以防止程序重復啟動，後面那個進程搶不到port，自然就沒法初始化了，避免造成意料之外的結果；
與其他IPC相比，TCP協議的一個天生的好處是「可記錄、可重現」。tcpmp和Wireshark是解決兩個進程間協議和狀態爭端的好幫手，也是性能（吞吐量、延遲）分析的利器。我們可以藉此編寫分布式程序的自動化回歸測試。也可以用tcp之類的工具進行壓力測試。TCP還能跨語言，服務端和客戶端不必使用同一種語言。
分布式系統的軟體設計和功能劃分一般應該以「進程」為單位。從宏觀上看，一個分布式系統是由運行在多台機器上的多個進程組成的，進程之間採用TCP長連接通信。
使用TCP長連接的好處有兩點：一是容易定位分布式系統中的服務之間的依賴關系。只要在機器上運行netstat -tpna|grep <port>就能立刻列出用到某服務的客戶端地址（Foreign Address列），然後在客戶端的機器上用netstat或lsof命令找出是哪個進程發起的連接。TCP短連接和UDP則不具備這一特性。二是通過接收和發送隊列的長度也較容易定位網路或程序故障。在正常運行的時候，netstat列印的Recv-Q和Send-Q都應該接近0，或者在0附近擺動。如果Recv-Q保持不變或持續增加，則通常意味著服務進程的處理速度變慢，可能發生了死鎖或阻塞。如果Send-Q保持不變或持續增加，有可能是對方伺服器太忙、來不及處理，也有可能是網路中間某個路由器或交換機故障造成丟包，甚至對方伺服器掉線，這些因素都可能表現為數據發送不出去。通過持續監控Recv-Q和Send-Q就能及早預警性能或可用性故障。以下是服務端線程阻塞造成Recv-Q和客戶端Send-Q激增的例子：
[cpp] view plain
$netstat -tn
Proto Recv-Q Send-Q Local Address Foreign
tcp 78393 0 10.0.0.10:2000 10.0.0.10:39748 #服務端連接
tcp 0 132608 10.0.0.10:39748 10.0.0.10:2000 #客戶端連接
tcp 0 52 10.0.0.10:22 10.0.0.4:55572
五：多線程伺服器的適用場合
如果要在一台多核機器上提供一種服務或執行一個任務，可用的模式有：
a：運行一個單線程的進程；
b：運行一個多線程的進程；
c：運行多個單線程的進程；
d：運行多個多線程的進程；
考慮這樣的場景：如果使用速率為50MB/s的數據壓縮庫，進程創建銷毀的開銷是800微秒，線程創建銷毀的開銷是50微秒。如何執行壓縮任務？
如果要偶爾壓縮1GB的文本文件，預計運行時間是20s，那麼起一個進程去做是合理的，因為進程啟動和銷毀的開銷遠遠小於實際任務的耗時。
如果要經常壓縮500kB的文本數據，預計運行時間是10ms，那麼每次都起進程 似乎有點浪費了，可以每次單獨起一個線程去做。
如果要頻繁壓縮10kB的文本數據，預計運行時間是200微秒，那麼每次起線程似 乎也很浪費，不如直接在當前線程搞定。也可以用一個線程池，每次把壓縮任務交給線程池，避免阻塞當前線程（特別要避免阻塞IO線程）。
由此可見，多線程並不是萬靈丹(silver bullet)。
1：必須使用單線程的場合
據我所知，有兩種場合必須使用單線程：
a：程序可能會fork(2)；
實際編程中，應該保證只有單線程程序能進行fork(2)。多線程程序不是不能調用fork(2)，而是這么做會遇到很多麻煩：
fork一般不能在多線程程序中調用，因為Linux的fork只克隆當前線程的thread of control，不可隆其他線程。fork之後，除了當前線程之外，其他線程都消失了。
這就造成一種危險的局面。其他線程可能正好處於臨界區之內，持有了某個鎖，而它突然死亡，再也沒有機會去解鎖了。此時如果子進程試圖再對同一個mutex加鎖，就會立即死鎖。因此，fork之後，子進程就相當於處於signal handler之中（因為不知道調用fork時，父進程中的線程此時正在調用什麼函數，這和信號發生時的場景一樣），你不能調用線程安全的函數（除非它是可重入的），而只能調用非同步信號安全的函數。比如，fork之後，子進程不能調用：
malloc，因為malloc在訪問全局狀態時幾乎肯定會加鎖；
任何可能分配或釋放內存的函數，比如snprintf；
任何Pthreads函數；
printf系列函數，因為其他線程可能恰好持有stdout/stderr的鎖；
除了man 7 signal中明確列出的信號安全函數之外的任何函數。
因此，多線程中調用fork，唯一安全的做法是fork之後，立即調用exec執行另一個程序，徹底隔斷子進程與父進程的聯系。
在多線程環境中調用fork，產生子進程後。子進程內部只存在一個線程，也就是父進程中調用fork的線程的副本。
使用fork創建子進程時，子進程通過繼承整個地址空間的副本，也從父進程那裡繼承了所有互斥量、讀寫鎖和條件變數的狀態。如果父進程中的某個線程佔有鎖，則子進程同樣佔有這些鎖。問題是子進程並不包含佔有鎖的線程的副本，所以子進程沒有辦法知道它佔有了哪些鎖，並且需要釋放哪些鎖。
盡管Pthread提供了pthread_atfork函數試圖繞過這樣的問題，但是這回使得代碼變得混亂。因此《Programming With Posix Threads》一書的作者說：」Avoid using fork in threaded code except where the child process will immediately exec a new program.」。
b：限製程序的CPU佔用率；
這個很容易理解，比如在一個8核的伺服器上，一個單線程程序即便發生busy-wait，占滿1個core，其CPU使用率也只有12.5%，在這種最壞的情況下，系統還是有87.5%的計算資源可供其他服務進程使用。
因此對於一些輔助性的程序，如果它必須和主要服務進程運行在同一台機器的話，那麼做成單線程的能避免過分搶奪系統的計算資源。
『伍』 虛擬機linux如何聯網
1、在虛擬機中創建的「電腦」上，右鍵選則setting（設置）。
2、選擇NAT模式，然後點擊Edit--》virtual network editor,點擊vmnet8，裡面會有一些ip地址的信息，
『陸』 有名管道和無名管道的區別
無名管道和有名管道是Linux系統內核的特殊文件，用於進程之間的通信。
無名管道相當於一個隊列結構，fd[1]為寫入端（入隊），fd[0]為讀出端（出隊）。其中信息讀出後即刪除，再次讀取時即為下一個信息。
相關函數：[1]
函數形式：intpipe(int fd[2])
功能：創建無名管道文件。無名管道是一個特殊文件，不可由open函數創建。
參數：fd[2]有兩個成員 fd[0]和 fd[1]，他們都是文件描述符。 管道有固定的讀端 fd[0]和固定的寫端 fd[1]。
返回值：成功返回 0，出錯返回-1。
說明：
1.管道是創建在內存中，進程結束空間釋放，管道不復存在。
2.無名管道和有名管道都是半雙工通信，實現雙向通信需要建立兩個管道。
3.無名管道是linux特殊文件，不能在與windows共享的文件夾中創建。
4.無名管道只用於父子進程之間，有名管道可用於無親緣關系的進程之間。