今天，虽然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

描述

mach 命令显示系统处理器的体系结构。

退出状态

命令已经成功完成。

>0

发生错误。

示例

1. 要显示当前主机的处理器类型，请按以下方式使用 mach 命令：

mach

文件

/usr/bin/mach 包含 System V mach 命令。

mach3软件

在很多控制领域很流行

马赫数--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以上.

著名的奥地利物理学家、哲学家、音乐家--恩斯特·马赫(Ernst Mach,1838-1916)