在Unix-like系統(tǒng)進(jìn)行IPC(Inter-process communication)通信，Shared memory是效率最高的，我稱之為IPC的王中王。
　　主要IPC的方法
　　在Windows Mobile和Windows Embedded CE系統(tǒng)下，主要的IPC方法有以下幾種。
      方法通知數(shù)據(jù)存儲數(shù)據(jù)大小
Named events間接N/AN/A
Windows messages間接在Message中很小，只能傳輸Integer或者使用COPYDATASTRUCT 傳輸對象
Point-to-point message queues間接在Message中小型，存在boxing和unboxing問題

MSMQ直接在Message中小型，存在boxing和unboxing問題
TCP sockets直接直接發(fā)送流(stream)中度
Memory mapped filesN/Amapped file中度
RegistryN/A注冊表中度
File systemN/A文件大型
DatabaseN/A數(shù)據(jù)庫大型
WCFN/AWCF消息

　　上述表格參考了Interprocess Communication with the .NET Compact Framework 1.0
　　關(guān)于上述的IPC的方法，沒有那個最好，選擇的時候需要根據(jù)具體需求來決定。這篇文章主要關(guān)注Named events和Shared Memory。 我之前也寫過關(guān)于其他IPC方法的文章，可以參考如下：
　　Windows Message
　　.NET Compact Framework下的進(jìn)程間通信之Windows Message
　　MSMQ
　　WinCe和Windows Mobile下的MSMQ安裝
　　.NET Compact Framework下的進(jìn)程間通信之MSMQ開發(fā)
　　Registry
　　.NET Compact Framework下注冊表導(dǎo)出工具的開發(fā)
　　File System
　　Windows Mobile和Wince下使用TinyXML進(jìn)行Native C++的開發(fā)
　　Database
　　.NET Compact Framework下SQL CE的使用 (實(shí)現(xiàn)了SqlCeHepler的封裝SqlCeHepler的測試類，見.NET Compact Framework下的單元測試)
　　Windows Mobile下Native C++訪問SqlCe的封裝
　　SQL Server Express和SQL Server Compact的應(yīng)用
　　.NET Campact Framework下SQL CE兼容性問題
　　Windows Mobile下訪問Sqlite的Native C++封裝
　　如何壓縮SQLite的數(shù)據(jù)文件
　　還有Point-to-point message queues, TCP sockets等等一部分主題沒有寫，如果有人希望我總結(jié)出來，請留言，我后續(xù)會補(bǔ)充進(jìn)去。
　　Shared Memory的實(shí)現(xiàn)
　　實(shí)現(xiàn)的代碼主要參考了OpenNETCF的Smart Device Framework。
　　三個關(guān)鍵的類
　　MemoryMappedFile用于封裝共享內(nèi)存，在Windows Embedded CE下的共享內(nèi)存是一個Memory Mapped File，也就是一個內(nèi)存映射文件，在所有進(jìn)程的都可以訪問的內(nèi)存中映射文件，操作該共享內(nèi)存就類似于磁盤物理文件。所以繼承于Stream，通過流來讀寫。
　　NamedMutex是進(jìn)程級別的鎖，在Native C++一般使用CRITICAL_SECTION做鎖，而在.NET Compact Framework會使用monitor，微軟已經(jīng)把monitor封裝到lock關(guān)鍵字中了，注意這個lock不是函數(shù)，是C#語言內(nèi)嵌關(guān)鍵字。lock和Monitor等價(jià)。
　　關(guān)于lock和CRITICAL_SECTION的使用請參考下面文章。
　　Windows Mobile使用.NET Compact Framework開發(fā)多線程程序
　　Windows Mobile使用Native C++開發(fā)多線程程序
　　那么，既然有了lock和CRITICAL_SECTION為什么還需要Mutex呢，從性能來說Mutex的效率比Monitor也就是lock要低，所以我一般會使用lock而不是Mutex，但是lock不能支持跨進(jìn)程加鎖，所以在這個case，我使用了Mutex。
　　.NET Compact Framework本身就提供了一個Mutex的類，可惜只是支持無名Mutex。Mutex分為命名Mutex和無名Mutex，無名的Mutex只能在同一個進(jìn)程內(nèi)部使用，不能跨進(jìn)程使用，所以這里封裝了個NamedMutex來支持命名Mutex，從而支持跨進(jìn)程的鎖操作。
　　EventWaitHandle是通知Event。.NET Compact Framework本身封裝了AutoResetEvent和ManualResetEvent，但是他們都不支持跨進(jìn)程，所以封裝了EventWaitHandle來實(shí)現(xiàn)跨進(jìn)程的Event通知。
　　SharedMemoryWriter
　　SharedMemoryWriter負(fù)責(zé)往共享內(nèi)存寫數(shù)據(jù)。
 
　　
private void StartSharedMemoryWriting(){ MemoryMappedFile mmf = MemoryMappedFile.CreateInMemoryMap("SharedMemoryBlock"); int i = 100; while (started) { string s = "SharedMemory:" + i.ToString(); UpdateMessageList(s); byte[] dataBuffer = System.Text.ASCIIEncoding.ASCII.GetBytes(s); // Wait until it is safe to enter. mutex.WaitOne(); try { mmf.Position = 0; mmf.Write(dataBuffer, 0, dataBuffer.Length); } finally { // Release the Mutex. mutex.ReleaseMutex(); } // Raise the event namedEvent.Set(); ++i; if (i > 999) { i = 100; } System.Threading.Thread.Sleep(500); } mmf.Close();}生成系統(tǒng)唯一命名的共享內(nèi)存，在這個例子中使用了SharedMemoryBlock。每次寫共享內(nèi)存的時候都通過Named Mutex對該內(nèi)存加鎖。當(dāng)寫完畢后通過Named Event通知SharedMemoryReader(讀共享內(nèi)存)的進(jìn)程。
　　SharedMemoryReader
　　SharedMemoryReader負(fù)責(zé)讀取共享內(nèi)存的數(shù)據(jù)。
 
　　
private void StartSharedMemoryReading(){ MemoryMappedFile mmf = MemoryMappedFile.CreateInMemoryMap("SharedMemoryBlock"); byte[] dataBuffer = new byte[1024; while (started) { if (namedEvent.WaitOne()) { if (!started) { break; } namedEvent.Reset(); // Wait until it is safe to enter. if (mutex.WaitOne()) { try { mmf.Position = 0; mmf.Read(dataBuffer, 0, 50); } finally { // Release the Mutex. mutex.ReleaseMutex(); } } string s = System.Text.ASCIIEncoding.ASCII.GetString(dataBuffer, 0, 50); UpdateMessageList(s); } } mmf.Close();}打開同樣名字(SharedMemoryBlock)的共享內(nèi)存，這個進(jìn)程會掛起直到收到Named Event的消息，每次讀取的時候都需要使用Named Mutex來加鎖。