-- 作者：wangxinxin
-- 發(fā)布時間：2010-11-26 9:00:01
-- WindowsMobile開發(fā)技術(shù)淺析，WinCE在.NET框架下的應(yīng)用
在Unix-like系統(tǒng)進行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下的進程間通信之Windows Message
MSMQ
WinCe和Windows Mobile下的MSMQ安裝
.NET Compact Framework下的進程間通信之MSMQ開發(fā)
Registry
.NET Compact Framework下注冊表導(dǎo)出工具的開發(fā)
File System
Windows Mobile和Wince下使用TinyXML進行Native C++的開發(fā)
Database
.NET Compact Framework下SQL CE的使用 (實現(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ù)會補充進去。
Shared Memory的實現(xiàn)
實現(xiàn)的代碼主要參考了OpenNETCF的Smart Device Framework。
三個關(guān)鍵的類
MemoryMappedFile用于封裝共享內(nèi)存，在Windows Embedded CE下的共享內(nèi)存是一個Memory Mapped File，也就是一個內(nèi)存映射文件，在所有進程的都可以訪問的內(nèi)存中映射文件，操作該共享內(nèi)存就類似于磁盤物理文件。所以繼承于Stream，通過流來讀寫。
NamedMutex是進程級別的鎖，在Native C++一般使用CRITICAL_SECTION做鎖，而在.NET Compact Framework會使用monitor，微軟已經(jīng)把monitor封裝到lock關(guān)鍵字中了，注意這個lock不是函數(shù)，是C#語言內(nèi)嵌關(guān)鍵字。lock和Monitor等價。
關(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不能支持跨進程加鎖，所以在這個case，我使用了Mutex。
.NET Compact Framework本身就提供了一個Mutex的類，可惜只是支持無名Mutex。Mutex分為命名Mutex和無名Mutex，無名的Mutex只能在同一個進程內(nèi)部使用，不能跨進程使用，所以這里封裝了個NamedMutex來支持命名Mutex，從而支持跨進程的鎖操作。
EventWaitHandle是通知Event。.NET Compact Framework本身封裝了AutoResetEvent和ManualResetEvent，但是他們都不支持跨進程，所以封裝了EventWaitHandle來實現(xià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)存)的進程。
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)存，這個進程會掛起直到收到Named Event的消息，每次讀取的時候都需要使用Named Mutex來加鎖。
|