Mach是一個由卡內基梅隆大學開發的用於支持作業系統研究的作業系統核心，為了用於作業系統之研究，特別是在分散式與並行運算上。是最早實現微核心作業系統的例子之一，是許多其它相似的項目的標準。
基本介紹
- 外文名：Mach
- 屬性：作業系統核心
Mach （kernel）,mach 命令,Mach 馬赫,簡介,遊戲,人名,
Mach （kernel）
Mach是一個由卡內基梅隆大學開發的用於支持作業系統研究的作業系統核心。
該項目在1985年啟動，並且在1994年因為mach3.0的顯著失敗而告終。但是mach卻是一個真正的微核。mach被開發成了UNIX中BSD的替代核心，所以沒必要再開發設計他的衍生系統。
該項目在1985年啟動，並且在1994年因為mach3.0的顯著失敗而告終。但是mach卻是一個真正的微核。mach被開發成了UNIX中BSD的替代核心，所以沒必要再開發設計他的衍生系統。
其他還有許多人繼續Mach的研究包括猶他大學的Mach 4。Mach的開發是為了取代BSD的UNIX核心，所以是許多新的作業系統的設計基礎。Mach的研究到至今似乎是退出，雖然有許多商業化作業系統，如NEXTSTEP與OPENSTEP，特別是Mac OS X（使用XNU核心）都是使用Mach或其派生系統。Mach的虛擬記憶體（VM）系統也被BSD的開發者用於CSRG，並出現在BSD派生的系統中，如FreeBSD。Mac OS X與FreeBSD並未保留Mach首倡的微核心結構，除了Mac OS X繼續提供微核心於內部處理通信以及應用程式直接控制。
Mach繼承卡內基梅隆大學的Accent kernel，Mach項目主導人理察·拉希德曾於微軟的研究部門擔任高級人員，後成為微軟副總裁。另一Mach開發者阿瓦德斯·特凡尼安（Avie Tevanian）曾是NeXT首席程式設計師，之後擔任蘋果電腦軟體技術部門主管直到2006年。
現在，一個名為GNU Mach的計畫與GNU HURD聯繫緊密。Debian GNU/Hurd就是基於GNU Mach的。
今天，雖然mach及其衍生品在許多商業作業系統被廣泛使用，但是對mach的進一步實驗研究已經結束。例如,OPENSTEP NeXTSTEP,最明顯的是Mac OS X作業系統核心，他使用XNU其中包括一個早期(非微核)mach作為主要組件。
歷史
Mach概念
由於設計Mach的目的是作為一個“不速之客”替代傳統的UNIX核心，對Mach的討論重點是mach和UNIX的區別。由於馬赫的目的是作為一個“降”替代傳統的UNIX核心，這個討論的重點是從UNIX的區別馬赫。UNIX“把一切事物作為檔案”的理念在現代系統上可能還沒有普及，即使已經有一些系統，比如貝爾實驗室的Plan 9，嘗試了這種方式。然而，許多開發商感嘆傳統理念對於靈活性考慮的損失。尋求另一個層面的虛擬化應該也能使系統一如往常地工作。
在UNIX 中最關鍵的抽象是管(pipe)的概念。我們需要的是一個在一個更一般的水平上的管(pipe)的概念，從而使程式之間能傳遞各種各樣的信息。這樣的系統使用進程間通信（inter-process communication，IPC）：一個管概念(pipe-like)的系統能在兩個程式間交換信息，但不同於類似檔案的信息。雖然有許多系統，包括大多數Unix系統中，在早先其僅作為單任務使用的專用庫時就已經增加了不同的IPC實現。
卡內基-梅隆大學在Accent Kernel項目中開始沿著這些想法進行了實驗，所使用的是基於共享記憶體的 IPC系統。Accent是一個許多功能的純粹的實驗性質的系統，以一種專有的方式在一段時間內伴隨著不斷變化的研究興趣而不斷發展。此外，雅紳特的用處是有限的，由於Accent不兼容UNIX，因此對於Accent的研究是受限的，當時UNIX已經是在幾乎所有的作業系統研究的標準。最後，Accent和硬體平台是緊耦合的，而在20世紀80年代初，新的平台爆炸性的出現，其中許多是大規模並行性質的.
Mach開始主要是作為一個明確定義的，基於UNIX的，高度可移植的成果。其包含以下的一般概念：
1“ 任務 “是由一組對象組成的為”執行緒“提供運行能力的系統資源組成的
2“ 執行緒 “是一個單一的執行單元，存在於一個任務的上下文和共享任務的資源
3“ 連線埠 “是一個受保護的任務之間訊息佇列，任務之間的通信任務擁有每個連線埠的傳送和接收的權利
4“ “訊息 “是數據對象的集合，他們只能被傳送到連線埠，而不是特定的任務或執行緒
雖然馬赫的開發是基於Accent的IPC的概念，但其使系統更加地類似於UNIX，甚至可以直接運行很少或根本沒有修改的UNIX程式。要做到這一點，馬赫引入了一個連線埠（port)的概念，其每個端點的雙向IPC。連線埠如UNIX下的檔案一樣有安全性和許可權，允許類似UNIX的保護模式在其操作平台上套用。此外，，為了讓用戶程式如和硬體互動般處理任務，馬赫允許任何程式處理任務。
和UNIX作業系統一樣，Mach再次成為主要實用工具的集合。與UNIX相比，馬赫保持了處理硬體驅動程式的概念。因此，所有的硬體的驅動程式都必須包含在微核心中。其他基於硬體抽象層或exokernels的架構能將驅動程式移出微核心。
和UNIX的主要區別是，Mach不是處理檔案的實用工具，他們更多的用於處理任何“任務”。更多作業系統的代碼被出核心放入到用戶空間，從而產生了更小的核心及其崛起式的發展。與傳統系統不同的是，在Mach中，程式或“任務”可以包含的多個執行緒。雖然在現代系統中，多執行緒是常見的，但馬赫是第一個以多執行緒方式處理任務的系統。
連線埠概念和IPC的使用也許是馬赫和傳統的核心之間最根本的區別。在UNIX下，調用核心的操作被稱為一個系統調用（syscall）或陷阱（trap）。程式在共有的存儲中存放數據，然後會導致中斷（fault），或者說是某種類型的錯誤。當系統第一次啟動時核心處理所有的異常，所以當某個程式產生了異常，核心接管該異常，檢查傳遞來的異常信息，然後進行處理。
IPC系統率先被使用於Mach核心。為了調用系統的功能，程式會向核心申請一個連線埠通道，然後使用IPC系統將訊息傳送到該連線埠。
使用IPC傳遞訊息受益於執行緒和並發性。由於任務是由運用IPC方法的多執行緒組成的，馬赫能凍結和解凍執行緒從而同時處理訊息。這使得系統能分布在多個處理器上，可以直接使用共享記憶體，或添加代碼到另一個處理器。在傳統的核心中這是很難實現的：系統必須確保不同的程式沒有從不同的處理器嘗試寫入到相同的記憶體。在Mach中，這是定義良好，易於實現的：連線埠是一個良好的方法。
由於IPC系統最初的性能問題，所以一些戰略發展的影響較小。和它的前輩Accent一樣，Mach用一個單一的共享記憶體機制將訊息從一個程式傳遞到另一個程式。由於物理性地複製信息太慢，所以，馬赫運用本機的存儲器管理單元（MMU），快速在程式之間傳遞數據。只有當數據必須要求物理複製時，這個過程被稱為寫時複製（copy-on-write）的。
訊息也由核心進行有效性檢查，以避免錯誤的數據使某個系統程式崩潰。連線埠（Port）是UNIX檔案系統概念下嚴謹的模型。這允許用戶利用現有的檔案系統導航概念找到連線埠，就像在檔案系統中分配權利和許可權一樣。
這樣的系統的發展會變得更容易。代碼不僅能使用現有的工具在傳統的系統中工作，也以相同的方式被運行，調試及關閉。在monokernel中新的代碼中的錯誤可能導致整個機器需要重新啟動，而在Mach下，這將只需要重新啟動程式。此外，用戶可以定製系統，添加或排除他們需要的功能。由於作業系統是一個簡單的程式集合，他們通過運行或關閉程式從而添加或刪除部分內容。
最後，Mach的所有這些功能都是被刻意設計的以實現中立的平台的作用。但無疑Mach有許多缺點。其中一個相對一般的缺陷是還不清楚如何找到連線埠。在UNIX下，解決這個問題是程式設計師同達成一致劃出一些“眾所周知”在檔案系統中的位置，各司其職。當Mach中的連線埠也以同樣的方法處理這個問題時，在Mach核心下的作業系統被認為是更為流暢的，由於管道（port）的良好性能。如果沒有某種機制來查找連線埠和他們所代表的服務，這種靈活性將丟失。
名稱由來
據Tevanian說，MACH，源於一個讀音錯誤。當時他正和其他人在匹茲堡一個下雨天裡一邊躲避著路上的泥水坑，一邊討論著新核心的事，Tevanian開玩笑地建議他們的新微核命名為MUCK，意為“多用戶通信核心”（Multi-User Communication Kernel）或“多通用通訊核心”（Multiprocessor Universal Communication Kernel）。而一個義大利同事錯將MUCK發錯音為MACH後，拉希德覺的不錯並採用了MACH。
發展
Mach最初是作為附加支持編寫的代碼直接進入現有的4.2 BSD核心,允許團隊工作在系統很早之前完成。工作開始於語音IPC /連線埠,並轉移到其他作業系統的關鍵部分,任務和執行緒和虛擬記憶體。為完成部分的各個部分被重寫,BSD系統調用Mach,一個變化到4.3 BSD也在這個過程。
在1986年之前Mach系統被完成以便能夠獨立在DEC VAX上運行。雖然幾乎沒有實用價值，製造一個微核心的目標還是實現了。不久之後,借鑑學習Mach的IBM PC / RT上以及以SunMicrosystems68030為基礎的工作站，證明了這個系統的可移植性。到1987年，包括 Encore Multimax和Sequent Balancemachines，它們檢驗了Mach在多處理器系統上運行的能力。那一年公開發行了Mach第一版，並在第二年發布了第二版。
在這段時間內，一個“真正的”微核心的目的並沒有被實現。這些早期的Mach的版本包括了大多數基於核心的4.3BSD——一個被稱作POE伺服器的系統，從而導致了核心要遠遠大於它在UNIX中的時候。然而這個想法將UNIX層從核心移動到用戶空間，使它能夠更輕易的工作甚至被完全地取代。不幸的是，性能成為了一個主要的問題，同時人們為了解決這一問題也做了許多構造上的改變來。笨重的UNIX的許可問題也在折磨著研究者們。所以這個早期的為提供一個非許可類的類似於UNIX的系統環境而做的努力順利的進入Mach的進一步發展。
由此產生的Mach3在1990年發布，並且引起了當時很多人的興趣。一個小的團隊已經建立了Mach並且將它移植到一些平台上，其中包括為老式核心造成嚴重問題的複雜的多核處理器。這在當時的商業市場上產生了相當大的反響，其中一些公司正在糾結是否要改變硬體平台。如果現有的系統能夠在Mach上面運行，改變下面的平台似乎會變得容易。
當開放軟體基金會（OSF）宣布他們將在Mach 2.5上運行未來的OSF/1版本的時候，Mach的知名度有了一個重要的提高，並且同時也在研究Mach3。Mach 2.5 還被 NeXTSTEP系統以及許多商業的多核處理器供應商所選擇。Mach 3 使許多人努力將其他的系統部分移植到微核上，包括IBM的Workplace OS 以及蘋果公司努力建造一個跨平台版本的MAC OS。
性能問題
Mach原本是打算要取代經典的UNIX核心，基於這個原因，也包含了許多UNIX-like 的想法。例如，MACH使用了許可權管理和基於UNIX檔案系統的安全系統。由於核心（運行在核心空間 kernel-space）對其他作業系統的伺服器和軟體擁有特權，而這可能可能引發故障或惡意程式傳送命令導致系統損壞，出於這個原因核心會檢查每條訊息的有效性。另外，大多數作業系統的功能是在用戶空間user-space運行，這就意味著，需要為核心提供某種方式以為這些計畫授予額外的許可權，例如在硬體上運行。
Mach的一些更高級功能也是基於這個相同的IPC機制。例如，Mach能夠輕鬆支持多處理器的機器。對於傳統核心，大量的工作需要進行時，使其重入或中斷 ，在不同的處理器上運行的程式可以同時被核心調用。而在Mach核心中，位的作業系統能像任何其他程式一樣，獨立地運行在任何處理器上，因為它們是被隔離在伺服器中的。雖然在理論上Mach核心也必須是可重入的，在實際中，這是不是一個問題，因為它的回響時間是如此之快，它可以簡單地等待服務請求轉。Mach還包括一個伺服器，不僅可以在程式之間將訊息轉發，甚至是在網路上，這在20世紀80年代末和90年代初是一個蓬勃發展的領域。
不幸的是，將IPC用於幾乎所有的任務對性能產生了嚴重影響。於1997年進行的硬體基準測試表明，基於UNIX的Mach 3.0單台伺服器實現，比原生UNIX慢了約50%。研究顯示，絕大多數的性能使用，73%是由於IPC的開銷引起的，這是在單一大型伺服器提供作業系統的系統上的結果，而在較小的伺服器上問題只會變得更糟。用它實現一個集合的伺服器更是根本不可能的目標。
儘管進行了許多努力，以改善Mach，Mach-like微核心的性能，到了20世紀90年代中期，大部分早期對MACH的濃厚的興趣已經消失殆盡。基於IPC的作業系統的概念死掉了，這個想法本身有著缺陷。事實上，對確切性能問題的進一步研究揭示了一系列有趣的事實。其中之一是，IPC本身並不是問題所在：儘管有一些開銷與需要來支持它的存儲器映射，但是，這僅僅增加了少量的時間需求。其餘80%的時間，是由於核心上運行的訊息產生的額外的任務。其中主要是連線埠的許可權檢查和信息的有效性。在486 DX-50的基準測試中，標準的UNIX系統平均使用了21 微秒完成，而相同的操作Mach IPC平均花費114微秒。其中與硬體相關的僅18微秒，其餘的是Mach核心上運行的程式的各種訊息。在什麼也不做的情況下，一個完整的BSD系統調用需要大約40微秒的時間，而在用戶空間Mach系統下不足500微秒。
Mach第一次嚴格地套用是在2.x版本，性能比傳統的單片作業系統慢，可能高達25%，但是並未令人擔憂，=，因為該系統還提供支持多處理器支持以及具備較高的可移植性。許多人認為這是一個預期內可接受的成本開銷。Mach 3 版本時，試圖移動作業系統的大部分到用戶空間，但是開銷仍然較高：在一個MIPS R3000上進心的基準測試表明Mach和UNIX之間存在著極大地效能差異，因某些工作負載中能高達67%。
例如，獲取系統時間的操作就涉及一個IPC調用維持系統時鐘的用戶空間服務。調用者第一次進入核心，引起上下文切換和記憶體映射。核心隨後會檢查調用者的訪問許可權，以及該訊息是否有效。如果是，還有另外一個上下文切換和記憶體映射以完成對用戶空間服務的調用。過程中必須重複返回結果，總共達4次的上下文切換和記憶體映射，再加上兩個訊息驗證。這樣的開銷又迅速結合更複雜的往往是通過多台伺服器代碼路徑的服務。
這不是唯一的性能問題的根源。另一個集中的問題發生在試記憶體降低而分頁必須進行時如何正確處理操作記憶體。在傳統的單片作業系統核心部分，核心的各部分調用的分頁區域都十分明確，使其能夠調整調用避開將要使用的分頁部分。在Mach，這是不可能的，因為核心並不知道作業系統真正包括了些什麼。因此，作為替代，他們不得不使用了一個單一的一刀切的方案作為性能問題解決方案。Mach 3試圖通過提供一個簡單的分頁機解決這個問題，依靠用戶空間的分頁機具有更好的針對性。但事實證明，這沒有什麼效果。在實踐中，它的任何好處都被昂貴的IPC調用開銷所抹滅了。
其它影響性能的問題在於Mach的多處理器支持。從20世紀80年代中期到90年代初，商用CPU的性能約以60%的速度增長，但記憶體讀取速度只有7%的增長。這意味著訪問記憶體的成本在此期間大大增加，因為基於映射記憶體的MACH程式，任何“高速快取未命中”都會導致IPC調用變慢。
無論Mach的方法有著怎樣的優點，其現實世界中的性能表現是不能被接受的。當其團隊也得出同樣的結果後，早期在Mach上熱情很快就消失了。在很短的里，很多的發社區似乎就得出了這樣的結論：以IPC為基礎的作業系統的整個概念有著天生的缺陷。
潛在的解決方案
對於Mach 3系統來說IPC的開銷是一個主要的問題。然而，一個多伺服器的作業系統的概念仍然是有希望的，但是，這仍需要進行一些研究。開發人員需要很小心的不從伺服器到伺服器的將代碼分離成塊。例如，大多數網路代碼會被放在一個單獨的伺服器里，從而最大限度地減少IPC正常的網路任務。大多數開發人員堅持用原先的一個單一的大型伺服器提供作業系統功能的POE概念。為了簡化開發，他們允許作業系統伺服器在用戶空間或者核心空間上運行。這也使他們在用戶空間發展並且能夠擁有原先Mach思想的所有優勢，然後再把調試伺服器移動到核心空間裡面從而得到更好的性能表現。一些作業系統至今還在沿用這個被稱為“co-location”的思想，其中包括 Lites, MkLinux, OSF/1 和NeXTSTEP/OPENSTEP/Mac OS X. Chorus microkernel通過運用內置的機制允許伺服器被提升進核心空間，這也成為了一個基本系統的特色。
Mach 4 試圖解決這些問題，這次運用了更徹底的升級。特別地，人們發現，程式代碼通常是不可寫的，由於邊複製邊寫是罕見的，因而是如此潛在的衝擊。因此它使得別人認為在IPC的程式間不需要詳細的規劃記憶體，而是移動那些被用在程式中當地空間的程式代碼。由此產生了“shuttles”的概念，並且看上去性能也有所提升。然而，開發者們繼續在一個半可用狀態的系統上工作。Mach 4 同時也介紹了內置co-location的說法，使它成為核心本身的一個部分。
到了20世紀90年代中期，微核系統上的工作大部分都結束了，儘管市場普遍相信所有的現代作業系統在90年代結束之前會成為基於微核的系統。剩下的唯一使用到Mach 核心的地方是在蘋果的Mac OS X以及IOS上面，它們運行在經過重大修改的Mach 3 核心之上。
第二代微核心
進一步的分析表明,IPC的性能問題並沒有那么明顯。回想一下，一個系統調用的單側在BSD下花了20μs ，然而在同樣的系統中Mach用了114μs 。在這114μs中，11μs是由於上下文的轉換，這個與BSD是相同的。額外的18μs被MMU用來映射用戶空間和核心空間之間的信息。這個只增加了31μs，比傳統的系統調用用時久，但是並不是很久。
其餘的多數的實際問題，是由於核心的執行任務，例如為連線埠的訪問許可權檢查信息。雖然這似乎是一個重要的安全問題，但是，實際上它只在UNIX-like系統中起作用。例如，一個在手機或者機器人上運行的單用戶作業系統也許不需要任何這些特色，同時這確實是那種能使Mach的pick-and-choose 作業系統達到最大價值的系統。同樣當記憶體被另一個只在系統有超過一個地址空間時才真正起作用的作業系統移動時Mach產生了問題。DOS和早期的Mac OS有一個單獨的大的地址空間由所有的程式所共享，所以在這些系統中映射並沒有提供任何好處。
這些認識帶來了一系列的第二代微核心，更進一步的減少了系統的複雜性並且幾乎代替了用戶空間中所有的功能。例如，L4核心（版本2）只包括七個系統調用，使用了12k的記憶體，而Mach3包括月140個功能，使用了約330k的記憶體。在L4中一個486DX-50的IPC調用只花了5μs,比在同樣系統中的運行的UNIX系統調用快超過20倍。當然這個忽略了L4沒有解決全縣管理或者安全問題的事實，他們可以根據他們的需要選擇儘可能多或儘可能少的開銷。
L4潛在的性能提升被用戶空間應用程式經常需要提供許多由核心提供的功能這個事實所證明。為了測試‘end-to-end’的性能，co-located 代碼上的MkLinux被拿來與在用戶空間上運行的L4連線埠作比較。與Mach的15%比較嗎，L4增加了大約5%–10%的開銷。
這些更新的微核心整體上振興了這個產業，同時諸如GNU Hurd之類的計畫最終獲得了新的關注。
由於設計Mach的目的是作為一個“不速之客”替代傳統的UNIX核心，對Mach的討論重點是mach和UNIX的區別。由於馬赫的目的是作為一個“降”替代傳統的UNIX核心，這個討論的重點是從UNIX的區別馬赫。UNIX“把一切事物作為檔案”的理念在現代系統上可能還沒有普及，即使已經有一些系統，比如貝爾實驗室的Plan 9，嘗試了這種方式。然而，許多開發商感嘆傳統理念對於靈活性考慮的損失。尋求另一個層面的虛擬化應該也能使系統一如往常地工作。
在UNIX 中最關鍵的抽象是管(pipe)的概念。我們需要的是一個在一個更一般的水平上的管(pipe)的概念，從而使程式之間能傳遞各種各樣的信息。這樣的系統使用進程間通信（inter-process communication，IPC）：一個管概念(pipe-like)的系統能在兩個程式間交換信息，但不同於類似檔案的信息。雖然有許多系統，包括大多數Unix系統中，在早先其僅作為單任務使用的專用庫時就已經增加了不同的IPC實現。
卡內基-梅隆大學在Accent Kernel項目中開始沿著這些想法進行了實驗，所使用的是基於共享記憶體的 IPC系統。Accent是一個許多功能的純粹的實驗性質的系統，以一種專有的方式在一段時間內伴隨著不斷變化的研究興趣而不斷發展。此外，雅紳特的用處是有限的，由於Accent不兼容UNIX，因此對於Accent的研究是受限的，當時UNIX已經是在幾乎所有的作業系統研究的標準。最後，Accent和硬體平台是緊耦合的，而在20世紀80年代初，新的平台爆炸性的出現，其中許多是大規模並行性質的.
Mach開始主要是作為一個明確定義的，基於UNIX的，高度可移植的成果。其包含以下的一般概念：
1“ 任務 “是由一組對象組成的為”執行緒“提供運行能力的系統資源組成的
2“ 執行緒 “是一個單一的執行單元，存在於一個任務的上下文和共享任務的資源
3“ 連線埠 “是一個受保護的任務之間訊息佇列，任務之間的通信任務擁有每個連線埠的傳送和接收的權利
4“ “訊息 “是數據對象的集合，他們只能被傳送到連線埠，而不是特定的任務或執行緒
雖然馬赫的開發是基於Accent的IPC的概念，但其使系統更加地類似於UNIX，甚至可以直接運行很少或根本沒有修改的UNIX程式。要做到這一點，馬赫引入了一個連線埠（port)的概念，其每個端點的雙向IPC。連線埠如UNIX下的檔案一樣有安全性和許可權，允許類似UNIX的保護模式在其操作平台上套用。此外，，為了讓用戶程式如和硬體互動般處理任務，馬赫允許任何程式處理任務。
和UNIX作業系統一樣，Mach再次成為主要實用工具的集合。與UNIX相比，馬赫保持了處理硬體驅動程式的概念。因此，所有的硬體的驅動程式都必須包含在微核心中。其他基於硬體抽象層或exokernels的架構能將驅動程式移出微核心。
和UNIX的主要區別是，Mach不是處理檔案的實用工具，他們更多的用於處理任何“任務”。更多作業系統的代碼被出核心放入到用戶空間，從而產生了更小的核心及其崛起式的發展。與傳統系統不同的是，在Mach中，程式或“任務”可以包含的多個執行緒。雖然在現代系統中，多執行緒是常見的，但馬赫是第一個以多執行緒方式處理任務的系統。
連線埠概念和IPC的使用也許是馬赫和傳統的核心之間最根本的區別。在UNIX下，調用核心的操作被稱為一個系統調用（syscall）或陷阱（trap）。程式在共有的存儲中存放數據，然後會導致中斷（fault），或者說是某種類型的錯誤。當系統第一次啟動時核心處理所有的異常，所以當某個程式產生了異常，核心接管該異常，檢查傳遞來的異常信息，然後進行處理。
IPC系統率先被使用於Mach核心。為了調用系統的功能，程式會向核心申請一個連線埠通道，然後使用IPC系統將訊息傳送到該連線埠。
使用IPC傳遞訊息受益於執行緒和並發性。由於任務是由運用IPC方法的多執行緒組成的，馬赫能凍結和解凍執行緒從而同時處理訊息。這使得系統能分布在多個處理器上，可以直接使用共享記憶體，或添加代碼到另一個處理器。在傳統的核心中這是很難實現的：系統必須確保不同的程式沒有從不同的處理器嘗試寫入到相同的記憶體。在Mach中，這是定義良好，易於實現的：連線埠是一個良好的方法。
由於IPC系統最初的性能問題，所以一些戰略發展的影響較小。和它的前輩Accent一樣，Mach用一個單一的共享記憶體機制將訊息從一個程式傳遞到另一個程式。由於物理性地複製信息太慢，所以，馬赫運用本機的存儲器管理單元（MMU），快速在程式之間傳遞數據。只有當數據必須要求物理複製時，這個過程被稱為寫時複製（copy-on-write）的。
訊息也由核心進行有效性檢查，以避免錯誤的數據使某個系統程式崩潰。連線埠（Port）是UNIX檔案系統概念下嚴謹的模型。這允許用戶利用現有的檔案系統導航概念找到連線埠，就像在檔案系統中分配權利和許可權一樣。
這樣的系統的發展會變得更容易。代碼不僅能使用現有的工具在傳統的系統中工作，也以相同的方式被運行，調試及關閉。在monokernel中新的代碼中的錯誤可能導致整個機器需要重新啟動，而在Mach下，這將只需要重新啟動程式。此外，用戶可以定製系統，添加或排除他們需要的功能。由於作業系統是一個簡單的程式集合，他們通過運行或關閉程式從而添加或刪除部分內容。
最後，Mach的所有這些功能都是被刻意設計的以實現中立的平台的作用。但無疑Mach有許多缺點。其中一個相對一般的缺陷是還不清楚如何找到連線埠。在UNIX下，解決這個問題是程式設計師同達成一致劃出一些“眾所周知”在檔案系統中的位置，各司其職。當Mach中的連線埠也以同樣的方法處理這個問題時，在Mach核心下的作業系統被認為是更為流暢的，由於管道（port）的良好性能。如果沒有某種機制來查找連線埠和他們所代表的服務，這種靈活性將丟失。
名稱由來
據Tevanian說，MACH，源於一個讀音錯誤。當時他正和其他人在匹茲堡一個下雨天裡一邊躲避著路上的泥水坑，一邊討論著新核心的事，Tevanian開玩笑地建議他們的新微核命名為MUCK，意為“多用戶通信核心”（Multi-User Communication Kernel）或“多通用通訊核心”（Multiprocessor Universal Communication Kernel）。而一個義大利同事錯將MUCK發錯音為MACH後，拉希德覺的不錯並採用了MACH。
發展
Mach最初是作為附加支持編寫的代碼直接進入現有的4.2 BSD核心,允許團隊工作在系統很早之前完成。工作開始於語音IPC /連線埠,並轉移到其他作業系統的關鍵部分,任務和執行緒和虛擬記憶體。為完成部分的各個部分被重寫,BSD系統調用Mach,一個變化到4.3 BSD也在這個過程。
在1986年之前Mach系統被完成以便能夠獨立在DEC VAX上運行。雖然幾乎沒有實用價值，製造一個微核心的目標還是實現了。不久之後,借鑑學習Mach的IBM PC / RT上以及以SunMicrosystems68030為基礎的工作站，證明了這個系統的可移植性。到1987年，包括 Encore Multimax和Sequent Balancemachines，它們檢驗了Mach在多處理器系統上運行的能力。那一年公開發行了Mach第一版，並在第二年發布了第二版。
在這段時間內，一個“真正的”微核心的目的並沒有被實現。這些早期的Mach的版本包括了大多數基於核心的4.3BSD——一個被稱作POE伺服器的系統，從而導致了核心要遠遠大於它在UNIX中的時候。然而這個想法將UNIX層從核心移動到用戶空間，使它能夠更輕易的工作甚至被完全地取代。不幸的是，性能成為了一個主要的問題，同時人們為了解決這一問題也做了許多構造上的改變來。笨重的UNIX的許可問題也在折磨著研究者們。所以這個早期的為提供一個非許可類的類似於UNIX的系統環境而做的努力順利的進入Mach的進一步發展。
由此產生的Mach3在1990年發布，並且引起了當時很多人的興趣。一個小的團隊已經建立了Mach並且將它移植到一些平台上，其中包括為老式核心造成嚴重問題的複雜的多核處理器。這在當時的商業市場上產生了相當大的反響，其中一些公司正在糾結是否要改變硬體平台。如果現有的系統能夠在Mach上面運行，改變下面的平台似乎會變得容易。
當開放軟體基金會（OSF）宣布他們將在Mach 2.5上運行未來的OSF/1版本的時候，Mach的知名度有了一個重要的提高，並且同時也在研究Mach3。Mach 2.5 還被 NeXTSTEP系統以及許多商業的多核處理器供應商所選擇。Mach 3 使許多人努力將其他的系統部分移植到微核上，包括IBM的Workplace OS 以及蘋果公司努力建造一個跨平台版本的MAC OS。
性能問題
Mach原本是打算要取代經典的UNIX核心，基於這個原因，也包含了許多UNIX-like 的想法。例如，MACH使用了許可權管理和基於UNIX檔案系統的安全系統。由於核心（運行在核心空間 kernel-space）對其他作業系統的伺服器和軟體擁有特權，而這可能可能引發故障或惡意程式傳送命令導致系統損壞，出於這個原因核心會檢查每條訊息的有效性。另外，大多數作業系統的功能是在用戶空間user-space運行，這就意味著，需要為核心提供某種方式以為這些計畫授予額外的許可權，例如在硬體上運行。
Mach的一些更高級功能也是基於這個相同的IPC機制。例如，Mach能夠輕鬆支持多處理器的機器。對於傳統核心，大量的工作需要進行時，使其重入或中斷 ，在不同的處理器上運行的程式可以同時被核心調用。而在Mach核心中，位的作業系統能像任何其他程式一樣，獨立地運行在任何處理器上，因為它們是被隔離在伺服器中的。雖然在理論上Mach核心也必須是可重入的，在實際中，這是不是一個問題，因為它的回響時間是如此之快，它可以簡單地等待服務請求轉。Mach還包括一個伺服器，不僅可以在程式之間將訊息轉發，甚至是在網路上，這在20世紀80年代末和90年代初是一個蓬勃發展的領域。
不幸的是，將IPC用於幾乎所有的任務對性能產生了嚴重影響。於1997年進行的硬體基準測試表明，基於UNIX的Mach 3.0單台伺服器實現，比原生UNIX慢了約50%。研究顯示，絕大多數的性能使用，73%是由於IPC的開銷引起的，這是在單一大型伺服器提供作業系統的系統上的結果，而在較小的伺服器上問題只會變得更糟。用它實現一個集合的伺服器更是根本不可能的目標。
儘管進行了許多努力，以改善Mach，Mach-like微核心的性能，到了20世紀90年代中期，大部分早期對MACH的濃厚的興趣已經消失殆盡。基於IPC的作業系統的概念死掉了，這個想法本身有著缺陷。事實上，對確切性能問題的進一步研究揭示了一系列有趣的事實。其中之一是，IPC本身並不是問題所在：儘管有一些開銷與需要來支持它的存儲器映射，但是，這僅僅增加了少量的時間需求。其餘80%的時間，是由於核心上運行的訊息產生的額外的任務。其中主要是連線埠的許可權檢查和信息的有效性。在486 DX-50的基準測試中，標準的UNIX系統平均使用了21 微秒完成，而相同的操作Mach IPC平均花費114微秒。其中與硬體相關的僅18微秒，其餘的是Mach核心上運行的程式的各種訊息。在什麼也不做的情況下，一個完整的BSD系統調用需要大約40微秒的時間，而在用戶空間Mach系統下不足500微秒。
Mach第一次嚴格地套用是在2.x版本，性能比傳統的單片作業系統慢，可能高達25%，但是並未令人擔憂，=，因為該系統還提供支持多處理器支持以及具備較高的可移植性。許多人認為這是一個預期內可接受的成本開銷。Mach 3 版本時，試圖移動作業系統的大部分到用戶空間，但是開銷仍然較高：在一個MIPS R3000上進心的基準測試表明Mach和UNIX之間存在著極大地效能差異，因某些工作負載中能高達67%。
例如，獲取系統時間的操作就涉及一個IPC調用維持系統時鐘的用戶空間服務。調用者第一次進入核心，引起上下文切換和記憶體映射。核心隨後會檢查調用者的訪問許可權，以及該訊息是否有效。如果是，還有另外一個上下文切換和記憶體映射以完成對用戶空間服務的調用。過程中必須重複返回結果，總共達4次的上下文切換和記憶體映射，再加上兩個訊息驗證。這樣的開銷又迅速結合更複雜的往往是通過多台伺服器代碼路徑的服務。
這不是唯一的性能問題的根源。另一個集中的問題發生在試記憶體降低而分頁必須進行時如何正確處理操作記憶體。在傳統的單片作業系統核心部分，核心的各部分調用的分頁區域都十分明確，使其能夠調整調用避開將要使用的分頁部分。在Mach，這是不可能的，因為核心並不知道作業系統真正包括了些什麼。因此，作為替代，他們不得不使用了一個單一的一刀切的方案作為性能問題解決方案。Mach 3試圖通過提供一個簡單的分頁機解決這個問題，依靠用戶空間的分頁機具有更好的針對性。但事實證明，這沒有什麼效果。在實踐中，它的任何好處都被昂貴的IPC調用開銷所抹滅了。
其它影響性能的問題在於Mach的多處理器支持。從20世紀80年代中期到90年代初，商用CPU的性能約以60%的速度增長，但記憶體讀取速度只有7%的增長。這意味著訪問記憶體的成本在此期間大大增加，因為基於映射記憶體的MACH程式，任何“高速快取未命中”都會導致IPC調用變慢。
無論Mach的方法有著怎樣的優點，其現實世界中的性能表現是不能被接受的。當其團隊也得出同樣的結果後，早期在Mach上熱情很快就消失了。在很短的里，很多的發社區似乎就得出了這樣的結論：以IPC為基礎的作業系統的整個概念有著天生的缺陷。
潛在的解決方案
對於Mach 3系統來說IPC的開銷是一個主要的問題。然而，一個多伺服器的作業系統的概念仍然是有希望的，但是，這仍需要進行一些研究。開發人員需要很小心的不從伺服器到伺服器的將代碼分離成塊。例如，大多數網路代碼會被放在一個單獨的伺服器里，從而最大限度地減少IPC正常的網路任務。大多數開發人員堅持用原先的一個單一的大型伺服器提供作業系統功能的POE概念。為了簡化開發，他們允許作業系統伺服器在用戶空間或者核心空間上運行。這也使他們在用戶空間發展並且能夠擁有原先Mach思想的所有優勢，然後再把調試伺服器移動到核心空間裡面從而得到更好的性能表現。一些作業系統至今還在沿用這個被稱為“co-location”的思想，其中包括 Lites, MkLinux, OSF/1 和NeXTSTEP/OPENSTEP/Mac OS X. Chorus microkernel通過運用內置的機制允許伺服器被提升進核心空間，這也成為了一個基本系統的特色。
Mach 4 試圖解決這些問題，這次運用了更徹底的升級。特別地，人們發現，程式代碼通常是不可寫的，由於邊複製邊寫是罕見的，因而是如此潛在的衝擊。因此它使得別人認為在IPC的程式間不需要詳細的規劃記憶體，而是移動那些被用在程式中當地空間的程式代碼。由此產生了“shuttles”的概念，並且看上去性能也有所提升。然而，開發者們繼續在一個半可用狀態的系統上工作。Mach 4 同時也介紹了內置co-location的說法，使它成為核心本身的一個部分。
到了20世紀90年代中期，微核系統上的工作大部分都結束了，儘管市場普遍相信所有的現代作業系統在90年代結束之前會成為基於微核的系統。剩下的唯一使用到Mach 核心的地方是在蘋果的Mac OS X以及IOS上面，它們運行在經過重大修改的Mach 3 核心之上。
第二代微核心
進一步的分析表明,IPC的性能問題並沒有那么明顯。回想一下，一個系統調用的單側在BSD下花了20μs ，然而在同樣的系統中Mach用了114μs 。在這114μs中，11μs是由於上下文的轉換，這個與BSD是相同的。額外的18μs被MMU用來映射用戶空間和核心空間之間的信息。這個只增加了31μs，比傳統的系統調用用時久，但是並不是很久。
其餘的多數的實際問題，是由於核心的執行任務，例如為連線埠的訪問許可權檢查信息。雖然這似乎是一個重要的安全問題，但是，實際上它只在UNIX-like系統中起作用。例如，一個在手機或者機器人上運行的單用戶作業系統也許不需要任何這些特色，同時這確實是那種能使Mach的pick-and-choose 作業系統達到最大價值的系統。同樣當記憶體被另一個只在系統有超過一個地址空間時才真正起作用的作業系統移動時Mach產生了問題。DOS和早期的Mac OS有一個單獨的大的地址空間由所有的程式所共享，所以在這些系統中映射並沒有提供任何好處。
這些認識帶來了一系列的第二代微核心，更進一步的減少了系統的複雜性並且幾乎代替了用戶空間中所有的功能。例如，L4核心（版本2）只包括七個系統調用，使用了12k的記憶體，而Mach3包括月140個功能，使用了約330k的記憶體。在L4中一個486DX-50的IPC調用只花了5μs,比在同樣系統中的運行的UNIX系統調用快超過20倍。當然這個忽略了L4沒有解決全縣管理或者安全問題的事實，他們可以根據他們的需要選擇儘可能多或儘可能少的開銷。
L4潛在的性能提升被用戶空間應用程式經常需要提供許多由核心提供的功能這個事實所證明。為了測試‘end-to-end’的性能，co-located 代碼上的MkLinux被拿來與在用戶空間上運行的L4連線埠作比較。與Mach的15%比較嗎，L4增加了大約5%–10%的開銷。
這些更新的微核心整體上振興了這個產業，同時諸如GNU Hurd之類的計畫最終獲得了新的關注。
mach 命令
用途
顯示當前主機的處理器類型。
語法
mach
描述
mach 命令顯示系統處理器的體系結構。
退出狀態
0
命令已經成功完成。
>0
發生錯誤。
示例
1. 要顯示當前主機的處理器類型，請按以下方式使用 mach 命令：
mach
檔案
/usr/bin/mach 包含 System V mach 命令。
mach3軟體
在很多控制領域很流行
Mach 馬赫
簡介
馬赫數--Mach Number是以奧地利物理學家馬赫命名的用來定義物體速度與音速之比的值，即音速倍數。其中又有細分多種馬赫數，如飛行器在空中飛行使用的飛行馬赫數、氣流速度之氣流馬赫數、複雜流場中某點流速之局部馬赫數等等。
一般標註方法為Mach或者M後加上數值,例如:
Mach2表示兩馬赫,即兩倍音速;M3.1則是3.1馬赫;M5+表示五馬赫以上.
遊戲
在飛行遊戲中,例如著名的鷹擊長空.
鷹擊長空里有一個CE5,即Campaign Expert戰役專家任務5,任務要求是在Mach2+飛行達到一小時.
由於音速是聲音的速度,受很多因素影響,在不同環境下速度不一致,也就是沒有固定值.
一般來講默認音速為340米/秒,換算過來就是1224千米/小時,那么兩馬赫就是2448KM/H,
但是專業空軍儀器換算中,M2應該是2450.16公里/小時,
所以想要完成任務,最後是保持在2450km/h以上,或者MPH在1523以上.
