多容器系统间共享系统资源的方法及装置与流程

本发明涉及计算机技术领域，具体而言，本发明涉及一种多容器系统间共享系统资源的方法，及一种多容器系统间共享系统资源的装置。

背景技术：

随着当今计算机技术的发展，终端设备的各项软硬件配置越来越高，一些高端配置的终端设备运行效果已和桌面设备的相应配置实现的效果接近，这为操作系统的虚拟化奠定了基础；另一方面，用户对于终端设备使用场景的多样性与日俱增，终端设备不仅用于日常生活娱乐，还用于工作学习等重要场景。随着用户的使用需求地不断提高，出现了同一终端设备中根据不同的用户需求提供不同运行环境的解决方案，如设置特定用户在特定的受限运行环境下使用终端设备，或为同一用户在终端设备中的不同使用场景设置不同的运行环境。因此急需在终端设备的不同运行环境中实现系统资源的共享。

现有技术中，仅解决了分布式系统的资源共享的访问方法，通过识别资源位于本地的当前互斥锁的标识来判断是否可访问该资源，但是，该方案仅局限于实现各个服务器间的系统资源共享，无法实现单机中各进程间的系统资源共享，且通过现有技术在分布式系统中共享系统资源的解决方案无法移植到单个终端设备中的多系统中以实现共享系统资源，现有技术中，并不存在多系统的单个终端设备中解决各个系统间共享系统资源的方案，因此，亟待一种在多系统的终端设备中解决各个系统间共享系统资源的方法。

技术实现要素：

为克服上述技术问题或者至少部分地解决上述技术问题，特提出以下技术方案：

本发明的实施例提出了一种多容器系统间共享系统资源的方法，包括：

当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；

基于系统资源相匹配的资源锁，确定系统资源的状态信息；

根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

优选地，还包括：

为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表；

其中，该方法还包括：

当任一系统资源对应的资源锁的状态信息发生变化时，更新资源锁的第一链表；

基于第一链表的更新信息，更新第二链表。

优选地，确定访问请求中与设备对应的系统资源相匹配的资源锁的步骤，包括：

确定访问请求中与设备对应的系统资源的资源锁标识；

基于系统资源的资源锁标识，从第二链表中确定与系统资源相匹配的资源锁的状态信息。

优选地，基于系统资源相匹配的资源锁，确定系统资源的状态信息，包括以下任一情形：

若与系统资源相匹配的资源锁的状态信息为已被持有，确定系统资源的状态信息为系统资源已被占用；

若与系统资源相匹配的资源锁的状态信息为未被持有，确定系统资源的状态信息为系统资源未被占用；

若与系统资源相匹配的资源锁的状态信息为不存在，创建系统资源相匹配的资源锁。

可选地，还包括：

确定访问请求中与设备对应的系统资源的处理类型；

当系统资源的状态信息为已被占用，根据系统资源的状态信息，对系统资源进行加锁，包括以下任一情形：

当处理类型为加锁时，等待直至系统资源被释放，获取系统资源，并对系统资源进行加锁；

当处理类型为尝试加锁时，返回加锁失败提示信息；

当处理类型为定时加锁时，在定时加锁的预定时长内等待系统资源被释放，若获取到系统资源，对系统资源进行加锁；若等待时长超过定时加锁的预定时长，返回加锁失败提示信息。

优选地，根据系统资源的状态信息，对系统资源进行加锁，包括：

当系统资源的状态信息为未被占用，获取系统资源，并对系统资源进行加锁。

可选地，系统资源的处理类型还包括解锁，该方法还包括：

基于系统资源的资源锁标识，确定与系统资源相匹配的资源锁是否存在于第一链表中；

若存在，对系统资源进行解锁。

可选地，若与系统资源相匹配的资源锁不存在于第一链表中，还包括：

基于系统资源的资源锁标识，确定与系统资源相匹配的资源锁是否存在于第二链表中；

若与系统资源相匹配的资源锁存在于第二链表中，判断系统资源相匹配的资源锁是否被访问请求持有；

若是，对系统资源进行解锁。

本发明的另一实施例提出了一种多容器系统间共享系统资源的装置，包括：

监测及确定模块，用于当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；

确定模块，用于基于系统资源相匹配的资源锁，确定系统资源的状态信息；

加锁及分配模块，用于根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

可选地，还包括：

创建模块，用于为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表；

其中，该装置还包括：

第一更新模块，用于当任一系统资源对应的资源锁的状态信息发生变化时，更新资源锁的第一链表；

第二更新模块，用于基于第一链表的更新信息，更新第二链表。

优选地，监测及确定模块，包括：

第一确定单元，用于确定访问请求中与设备对应的系统资源的资源锁标识；

第二确定单元，用于基于系统资源的资源锁标识，从第二链表中确定与系统资源相匹配的资源锁的状态信息。

优选地，确定模块用于以下任一情形：

若与系统资源相匹配的资源锁的状态信息为已被持有，确定系统资源的状态信息为系统资源已被占用；

若与系统资源相匹配的资源锁的状态信息为未被持有，确定系统资源的状态信息为系统资源未被占用；

若与系统资源相匹配的资源锁的状态信息为不存在，创建系统资源相匹配的资源锁。

本发明的实施例中，提出了一种多容器系统间共享系统资源的方案，当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁，为后续根据资源锁来确定是否能够访问与资源锁相匹配的系统资源提供了必要的前提保障；基于系统资源相匹配的资源锁，确定系统资源的状态信息，为后续确定是否能够对系统资源进行加锁提供了必要的前提保障，使得系统资源能够被合理地分配；根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问，实现了在多容器系统中，根据与系统资源相匹配的资源锁的状态信息，来对系统资源进行加锁处理，保证了该进程的访问请求能够对系统资源进行独占访问，避免了多个进程同时对同一系统资源进行访问时发生访问冲突而导致容器系统不能正常运行的情况，实现了系统资源在被独占访问的前提下，在多容器系统间实现系统资源的共享。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明中一个实施例的多系统终端设备中各容器系统间的关系示意图；

图2为本发明中另一实施例的多容器系统间共享系统资源的方法的流程图；

图3为本发明中又一实施例的多容器系统间共享系统资源的方法的流程图；

图4为本发明中再一实施例的多容器系统间共享系统资源的方法的流程图；

图5为本发明中另一实施例的多容器系统间共享系统资源的方法的流程图；

图6为本发明中另一实施例的多容器系统间共享系统资源的方法的流程图；

图7为本发明中另一实施例的多容器系统间共享系统资源的方法的流程图；

图8为本发明中另一实施例的多容器系统间共享系统资源的方法的流程图；

图9为本发明中另一实施例的多容器系统间共享系统资源的方法的流程图；

图10为本发明中又另一实施例的多容器系统间共享系统资源的装置的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本发明的实施例中的多操作系统包括至少两个操作系统，其中，操作系统可包括各种操作系统，例如android操作系统等。本发明的实施例中的多操作系统可基于多种虚拟技术来实现，下文以Linux系统下的容器技术为例来进行实施例的详述。其中，使用Linux容器技术实现的多操作系统，在每个容器中装入独立的操作系统，多个操作系统之间相互独立，且多个操作系统运行在同一台物理终端设备上。

下面结合附图具体介绍本发明实施例的技术方案。

本发明实施例的终端设备的内部结构的框架示意图如图1所示，包括：两个容器系统，容器系统container1和容器系统container2。container1和container2访问系统资源前，首先通过访问内核在各自的/dev目录下创建的设备文件system_lock来获取系统资源对应的资源锁，随后，根据获取到系统资源对应的资源锁，访问内核Kernel Driver中相应的系统资源。其中，在内核中管理所有系统资源对应的资源锁。

其中，本发明实施例中的容器系统，可以是设置在以Linux container(容器)虚拟化技术创建的容器中的操作系统。操作系统可以为传统意义上的Linux操作系统或Unix操作系统，也可以是基于Linux操作系统衍生出来的Android系统、Ubuntu系统或FireFox系统等，还可以为以Windows平台为基础的windows系统等等。实际上，本发明中的容器系统不限于前述例举的操作系统，可以涵盖所有能够在容器中运行的操作系统。

优选地，容器系统可以是上述传统的操作系统，也可以是对传统的kernel进行改进和/或在kernel之外(例如框架层和应用层)增加功能模块之后，得到的操作系统。其中，各个容器系统共享同一系统内核，当各容器中的操作系统为Linux操作系统或基于Linux操作系统衍生出来的系统时，各容器系统为基于Linux kernel namespace框架之上的，通过容器实例层，增加了对终端设备中设备资源的管理功能模块后，得到的操作系统。

优选地，容器系统可以通过预定义的通道或容器通道与其他容器系统进行通信，预定义的通道可以是socket(套接字)通道。

图2为本发明中一个实施例的多容器系统间共享系统资源的方法的流程图。

本发明的实施例中，各步骤所执行的内容概述如下：步骤S210：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；步骤S220：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S230：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

本发明的实施例中，提出了一种多容器系统间共享系统资源的方法，当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁，为后续根据资源锁来确定是否能够访问与资源锁相匹配的系统资源提供了必要的前提保障；基于系统资源相匹配的资源锁，确定系统资源的状态信息，为后续确定是否能够对系统资源进行加锁提供了必要的前提保障，使得系统资源能够被合理地分配；根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问，实现了在多容器系统中，根据与系统资源相匹配的资源锁的状态信息，来对系统资源进行加锁处理，保证了该进程的访问请求能够对系统资源进行独占访问，避免了多个进程同时对同一系统资源进行访问时发生访问冲突而导致容器系统不能正常运行的情况，实现了系统资源在被独占访问的前提下，在多容器系统间实现系统资源的共享。以下针对各个步骤的具体实现做进一步的说明：

步骤S210：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁。

具体地，当内核监测到来自任一容器系统的针对设备的访问请求时，根据与设备对应的系统资源及其相匹配的资源锁之间的对应关系，确定访问请求中与设备对应的系统资源相匹配的资源锁。

例如，在多容器系统的终端设备运行环境中，包括容器系统OS₁和容器系统OS₂，当内核监测到来自容器系统OS₁针对设备A的访问请求Request1时，根据预定的设备A对应的系统资源及其相匹配的资源锁之间的对应关系，确定访问请求Request1中与设备A对应的系统资源相匹配的资源锁的标识信息为Lock1。

步骤S220：基于系统资源相匹配的资源锁，确定系统资源的状态信息。

例如，根据与系统资源相匹配的资源锁Lock1的状态信息为未被持有，确定该系统资源的状态信息为未被占用。

步骤S230：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

例如，在多容器系统的终端设备运行环境中，包括容器系统OS1和容器系统OS₂，容器系统OS₁中的一个进程访问系统资源resources1，通过ioctl函数访问与resources1对应的设备A时，内核中的字符设备驱动根据已确定的系统资源resources1的状态信息为未被占用，对系统资源resources1进行加锁，并将加锁后的系统资源resources1分配至容器系统OS₁，以用于容器系统OS₁的该进程对系统资源resources1进行独占访问。

本领域技术人员可以了解到，ioctl是Linux设备驱动程序中对设备的I/O通道进行管理的函数；在用户空间，可使用ioctl系统调用来控制设备。所谓对I/O通道进行管理，就是对设备的一些特性进行控制，例如串口的传输波特率、马达的转速等等。

在一优选实施例中，如图3所示，该方法包括步骤S310、步骤S320、步骤S330和步骤S340；步骤S310：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；步骤S320：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S330：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问；步骤S340：为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表。

其中，第二链表中包括的各个资源锁的状态相关信息。

其中，状态相关信息包括但不限于：各个资源对应的资源锁的标识信息、各个资源锁的占用状态信息、各个资源锁的被占用的系统的标识信息及各个资源锁被占用的访问请求的标识信息。

其中，本优选实施例中的多容器系统的终端设备在步骤S310、步骤S320和步骤S330中执行的操作与图2所示的多容器系统的终端设备在步骤S210、步骤S220和步骤S230中执行的操作相同或相似，在此不再赘述。

例如，在多容器系统的终端设备运行环境中，包括容器系统OS₁和容器系统OS₂，通过在内核中调用字符设备创建函数来创建字符设备的设备驱动，并通过该设备驱动在内核中创建一个第二链表，第二链表存储终端设备所有的资源锁，第二链表中包括所有资源对应的资源锁的标识信息、各资源锁的占用状态信息、各资源锁的被占用的操作系统的标识信息及各资源锁被占用的访问请求的标识信息等，其中，第二链表可以被各个容器系统访问；当内核监测到容器系统OS₁和容器系统OS₂启动时，随后，通过内核中的字符设备驱动，分别在容器系统OS₁和容器系统OS₂中的/dev目录下创建对应的设备驱动文件，如设备文件system_lock；当容器系统OS₁中的一个进程访问系统资源resources1，并打开设备A的文件时，内核会返回一个该文件对应的文件描述符，随后通过内核中的字符设备驱动为该文件描述符创建一个第一链表，用于存储该文件描述符所持有的所有资源锁，包括系容器系统的标识信息、系统资源的标识信息及其持有的所有资源锁的标识信息。

本领域技术人员可以了解到，Linux的设备驱动程序在内核中的角色相当于一个个独立的“黑盒子”，使某个特定的硬件响应一个定义良好的内部编程接口，这些接口完全隐藏了设备的工作细节，驱动程序除了对外提供特定的接口外，任何实现细节对应用程序都是不可见的；用户的操作通过一组标准化的调用执行，而这些调用独立于特定的驱动程序，驱动程序的任务是把这些标准化调用映射到实际硬件的设备特有操作上。

Linux中设备和模块的分为三大类：字符设备、块设备和网络设备。本发明实施例中，在内核中创建的设备驱动以字符设备为例。字符设备是Linux内核抽象出来的一类设备，字符设备是能够像字节流一样被访问的设备，由字符设备驱动程序来实现这种特性；一个字符设备是一种字节流设备，对设备的存取只能按顺序按字节的存取而不能随机访问，字符设备没有请求缓冲区，所有的访问请求都是按顺序执行的。

在Linux系统中一切皆可以看成是文件，设备也不例外，设备以文件形式存在。文件可分为：普通文件、目录文件、链接文件和设备文件。文件描述符是内核为了高效管理已被打开的文件所创建的索引，其是一个非负整数，通常是小整数，用于指代被打开的文件，所有执行I/O操作的系统调用都通过文件描述符。

优选地，如图4所示，该方法包括步骤S410、步骤S420、步骤S430、步骤S440、步骤S450和步骤S460；步骤S410：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；步骤S420：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S430：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问；步骤S440：为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表；步骤S450：当任一系统资源对应的资源锁的状态信息发生变化时，更新资源锁的第一链表；步骤S460：基于第一链表的更新信息，更新第二链表。

其中，本优选实施例中的多容器系统的终端设备在步骤S410、步骤S420、步骤S430和步骤S440中执行的操作与图3所示的多容器系统的终端设备在步骤S310、步骤S320、步骤S330和步骤S340中执行的操作相同或相似，在此不再赘述。

例如，在多容器系统的终端设备运行环境中，包括容器系统OS₁和容器系统OS₂，若容器系统OS₁中访问的系统资源resources1所持有的所有资源锁包括Lock1和Lock2，当容器系统OS₁访问的系统资源resources1不再持有资源锁Lock2时，删除容器系统OS₁访问的系统资源resources1的第一链表信息中所持有资源锁Lock2的信息，并根据该第一链表的更新信息，更新内核中的第二链表，即在内核中第二链表中资源锁Lock2的占用状态信息中，删除对应的被系统资源resources1占用的相关信息。

优选地，如图5所示，该方法包括步骤S510、步骤S520、步骤S530和步骤S540；步骤510：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源的资源锁标识；步骤S520：基于系统资源的资源锁标识，从第二链表中确定与系统资源相匹配的资源锁的状态信息；步骤S530：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S540：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

其中，本优选实施例中的多容器系统的终端设备在步骤S530和步骤S540中执行的操作与图2所示的多容器系统的终端设备在步骤S220和步骤S230中执行的操作相同或相似，在此不再赘述。

例如，在多容器系统的终端设备运行环境中，包括容器系统OS₁和容器系统OS₂，当容器系统OS₁中的一个进程访问系统资源resources1，通过ioctl函数访问设备A时，内核中的字符设备驱动根据ioctl函数中与系统资源resources1相匹配的资源锁的标识信息，如Lock3，从内核中的第二链表中确定与系统资源resources1相匹配的资源锁Lock3的状态信息，如未被持有。

优选地，基于系统资源相匹配的资源锁，确定系统资源的状态信息，包括以下任一情形：

1)若与系统资源相匹配的资源锁的状态信息为已被持有，确定系统资源的状态信息为系统资源已被占用；例如，根据与系统资源resources1相匹配的资源锁Lock3的状态信息为已被持有，确定系统资源resources1的状态信息为已被占用。

2)若与系统资源相匹配的资源锁的状态信息为未被持有，确定系统资源的状态信息为系统资源未被占用；例如，根据与系统资源resources1相匹配的资源锁Lock3的状态信息为未被持有，确定系统资源resources1的状态信息为未被占用。

3)若与系统资源相匹配的资源锁的状态信息为不存在，创建系统资源相匹配的资源锁；例如，根据与系统资源resources1相匹配的资源锁Lock3的状态信息不存在，则在第二链表中创建系统资源resources1相匹配的资源锁Lock3。

优选地，如图6所示，该方法包括步骤S610、步骤S620、步骤S630、步骤S640、步骤S650、步骤S660和步骤S670；步骤S610：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；步骤S620：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S630：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问；步骤S640：为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表；步骤S650：当任一系统资源对应的资源锁的状态信息发生变化时，更新资源锁的第一链表；步骤S660：基于第一链表的更新信息，更新第二链表；步骤S670：确定访问请求中与设备对应的系统资源的处理类型。

其中，本优选实施例中的多容器系统的终端设备在步骤S610、步骤S620、步骤S630、步骤S640、步骤S650和步骤S660中执行的操作与图4所示的多容器系统的终端设备在步骤S410、步骤S420、步骤S430、步骤S440、步骤S450和步骤S460中执行的操作相同或相似，在此不再赘述。

例如，在多容器系统的终端设备运行环境中，包括容器系统OS1和容器系统OS₂，系统资源的处理类型包括加锁、尝试加锁和定时加锁中的任一项，根据ioctl函数中传入的参数，如Lock，可确定访问请求中与设备A对应的系统资源resources1的处理类型为加锁；根据ioctl函数中传入的参数，如Trylock，可确定访问请求中与设备A对应的系统资源resources1的处理类型为尝试加锁；根据ioctl函数中传入的参数，如Timelock，可确定访问请求中与设备A对应的系统资源resources1的处理类型为定时加锁。

优选地，当系统资源的状态信息为已被占用，根据系统资源的状态信息，对系统资源进行加锁，包括以下任一情形：

1)当处理类型为加锁时，等待直至系统资源被释放，获取系统资源，并对系统资源进行加锁；例如，当系统资源resources1的状态信息为已被占用，当确定访问请求中与设备A对应的系统资源resources1的处理类型为加锁时，等待直至系统资源resources1被释放后，获取系统资源resources1，并对系统资源resources1进行加锁处理。

2)当处理类型为尝试加锁时，返回加锁失败提示信息；例如，当系统资源resources1的状态信息为已被占用，当确定访问请求中与设备A对应的系统资源resources1的处理类型为尝试加锁时，则返回加锁失败提示信息，如“系统资源resources1被占用，加锁失败！”。

3)当处理类型为定时加锁时，在定时加锁的预定时长内等待系统资源被释放，若获取到系统资源，对系统资源进行加锁；若等待时长超过定时加锁的预定时长，返回加锁失败提示信息；例如，当系统资源resources1的状态信息为已被占用，当确定访问请求中与设备A对应的系统资源resources1的处理类型为定时加锁时，在定时加锁的预定时长内，如10分钟内，等待系统资源resources1被释放，若10分钟内系统资源resources1被释放，获取到系统资源resources1，对系统资源resources1进行加锁处理；若等待时长超过定时加锁的预定时长，即等待时长超过10分钟时，则返回加锁失败提示信息，如“系统资源resources1被占用，加锁失败！”。

通过本实施例，可实现根据系统资源的不同状态信息进行相应的处理操作，从而使得系统资源能够被充分的利益，同时也避免了对系统资源加锁后，产生死锁的情况，进一步使得系统资源能够高效的在各容器系统间进行共享。

优选地，如图7所示，该方法包括步骤S710、步骤S720和步骤S730；步骤S710：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；步骤S720：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S730：当所述系统资源的状态信息为未被占用，获取所述系统资源，并对所述系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

其中，本优选实施例中的多容器系统的终端设备在步骤S710和步骤S720中执行的操作与图2所示的多容器系统的终端设备在步骤S210和步骤S220中执行的操作相同或相似，在此不再赘述。

例如，当系统资源resources1的状态信息为未被占用，当确定访问请求中与设备A对应的系统资源resources1的处理类型为加锁或尝试加锁或定时加锁时，获取系统资源resources1，并对系统资源resources1进行加锁处理。

优选地，系统资源的处理类型还包括解锁，如图8所示，该方法包括步骤S810、步骤S820、步骤S830、步骤S840、步骤S850、步骤S860和步骤S870、步骤S880和步骤S890；步骤S810：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；步骤S820：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S830：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问；步骤S840：为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表；步骤S850：当任一系统资源对应的资源锁的状态信息发生变化时，更新资源锁的第一链表；步骤S860：基于第一链表的更新信息，更新第二链表；步骤S870：确定访问请求中与设备对应的系统资源的处理类型；步骤S880：基于系统资源的资源锁标识，确定与系统资源相匹配的资源锁是否存在于第一链表中；步骤S890：若存在，对系统资源进行解锁。

其中，本优选实施例中的多容器系统的终端设备在步骤S810、步骤S820、步骤S830、步骤S840、步骤S850、步骤S860和步骤S870中执行的操作与图6所示的多容器系统的终端设备在步骤S610、步骤S620、步骤S630、步骤S640、步骤S650、步骤S660和步骤S670中执行的操作相同或相似，在此不再赘述。

例如，在多容器系统的终端设备运行环境中，包括容器系统OS₁和容器系统OS₂，容器系统OS₁中的一个进程，如process1，访问系统资源resources1，通过ioctl函数访问与resources1对应的设备A时，根据ioctl函数中与系统资源resources1相匹配的资源锁的标识信息，如Lock1，若内核中的字符设备驱动确定与系统资源resources1相匹配的资源锁Lock1存在于设备A的文件描述符对应的第一链表中，随后内核中的字符设备驱动根据ioctl函数中传入的参数，如Unlock，可确定访问请求中与设备A对应的系统资源resources1的处理类型为解锁，并对系统资源resources1的资源锁Lock1进行解锁处理，解锁成功后，在设备A的文件描述符对应的第一链表中删除系统资源resources1相匹配的资源锁Lock1的相关信息，且在内核中第二链表中资源锁Lock1的占用状态信息中，删除对应的被系统资源resources1占用的相关信息；若内核中的字符设备驱动确定与系统资源resources1相匹配的资源锁Lock1不存在于设备A的文件描述符对应的第一链表中，则返回解锁失败的相关信息，如“对系统资源resources1的持有的资源锁Lock1解锁失败！”。

通过本实施例，使得系统资源能够及时的释放相应的资源锁，使得其他进程能够及时的访问该系统资源，提高了系统资源在各容器系统间的使用效率，避免了因独占访问而产生系统资源浪费的情况。

优选地，若与系统资源相匹配的资源锁不存在于第一链表中，如图9所示，该方法包括步骤S9010、步骤S9020、步骤S9030、步骤S9040、步骤S9050、步骤S9060、步骤S9070、步骤S9080、步骤S9090、步骤S9100和步骤S9110；步骤S9010：当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；步骤S9020：基于系统资源相匹配的资源锁，确定系统资源的状态信息；步骤S9030：根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问；步骤S9040：为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表；步骤S9050：当任一系统资源对应的资源锁的状态信息发生变化时，更新资源锁的第一链表；步骤S9060：基于第一链表的更新信息，更新第二链表；步骤S9070：确定访问请求中与设备对应的系统资源的处理类型；步骤S9080：基于系统资源的资源锁标识，确定与系统资源相匹配的资源锁是否存在于第一链表中；步骤S9090：基于系统资源的资源锁标识，确定与系统资源相匹配的资源锁是否存在于第二链表中；步骤S9100：若与系统资源相匹配的资源锁存在于第二链表中，判断系统资源相匹配的资源锁是否被访问请求持有；步骤S9110：若是，对系统资源进行解锁。

其中，本优选实施例中的多容器系统的终端设备在步骤S9010、步骤S9020、步骤S9030、步骤S9040、步骤S9050、步骤S9060、步骤S9070和步骤S9080中执行的操作与图8所示的多容器系统的终端设备在步骤S810、步骤S820、步骤S830、步骤S840、步骤S850、步骤S860、步骤S870和步骤S880中执行的操作相同或相似，在此不再赘述。

例如，接上例，若与系统资源resources1相匹配的资源锁Lock1不存在于与设备A的文件描述符对应的第一链表中，随后，基于系统资源resources1的资源锁标识Lock1，确定与系统资源resources1相匹配的资源锁Lock1是否存在于第二链表中，若与系统资源resources1相匹配的资源锁Lock1存在于第二链表中，根据第二链表中资源锁Lock1的被占用的操作系统的标识信息，如容器系统OS₁及资源锁Lock1被占用的访问请求的标识信息，如process1，可确定系统资源resources1相匹配的资源锁Lock1的被持有者与访问请求的容器系统OS₁的进程process1一致，随后，对系统资源resources1的资源锁Lock1进行解锁处理，解锁成功后，在设备A的文件描述符对应的第一链表中删除系统资源resources1相匹配的资源锁Lock1的相关信息，并在内核中的第二链表中资源锁Lock1的占用状态信息中，删除对应的被系统资源resources1占用的相关信息；若内核中的字符设备驱动确定与系统资源resources1相匹配的资源锁Lock1不存在于第二链表中，则返回解锁失败的相关信息，如“对系统资源resources1的持有的资源锁Lock1解锁失败！”。通过本实施例，当同一个进程同时多次打开同一设备时，由于生成了多个文件描述符对应的第一链表，系统资源持有的资源锁并不一定存在于每个第一链表中时，避免了因确定与系统资源相匹配的资源锁当不存在于其中一个第一链表中时即不对该系统资源相匹配的资源锁进行解锁的情况，从而保证了对系统资源相匹配的资源锁进行准确的解锁，进一步地，提高了系统资源在各容器系统间的使用效率。

优选地，在多容器系统的终端设备运行环境中，包括容器系统OS₁和容器系统OS₂，预定容器系统OS₁中的进程process1的优先级高于容器系统OS₂的进程process2，容器系统OS₁中的进程process1访问系统资源resources1时，通过ioctl函数访问与resources1对应的设备A时，内核中的字符设备驱动根据已确定的系统资源resources1的状态信息为已被容器系统OS₂的进程process2占用，随后根据容器系统OS₁的进程process1的优先级高于容器系统OS₂的进程process2，内核中的字符设备驱动强制结束容器系统OS₂的进程process2，从而释放系统资源resources1，随后容器系统OS₁的进程process1可获取到系统资源resources1并对其进行加锁，并将加锁后的系统资源resources1分配至容器系统OS₁，以用于容器系统OS₁的进程process1对系统资源resources1进行独占访问。

本领域技术人员可以了解到，当多个进程对同一系统资源进行访问时，对该系统资源的分配规则不限于上述对系统资源的抢占的分配方式，还包括创建系统资源分配优先级链表进行相应的分配等分配方式，在此不做限定。

通过本实施例，解决了多个进程对同一系统资源的访问方法，使得各个进程能够以合理的方式对同一系统资源的共享访问，避免了访问冲突的情况，保证了各容器系统能够高效正常的运行。

图10为本发明中又另一实施例的多容器系统间共享系统资源的装置的结构示意图。

本发明的实施例中，各模块所执行的内容概述如下：监测及确定模块1010当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁；确定模块1020基于系统资源相匹配的资源锁，确定系统资源的状态信息；加锁及分配模块1030根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

本发明的实施例中，提出了一种多容器系统间共享系统资源的装置，当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁，为后续根据资源锁来确定是否能够访问与资源锁相匹配的系统资源提供了必要的前提保障；基于系统资源相匹配的资源锁，确定系统资源的状态信息，为后续确定是否能够对系统资源进行加锁提供了必要的前提保障，使得系统资源能够被合理地分配；根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问，实现了在多容器系统中，根据与系统资源相匹配的资源锁的状态信息，来对系统资源进行加锁处理，保证了该进程的访问请求能够对系统资源进行独占访问，避免了多个进程同时对同一系统资源进行访问时发生访问冲突而导致容器系统不能正常运行的情况，实现了系统资源在被独占访问的前提下，在多容器系统间实现系统资源的共享。以下针对各个模块的具体实现做进一步的说明：

监测及确定模块1010用于当内核监测到来自任一容器系统的针对设备的访问请求时，确定访问请求中与设备对应的系统资源相匹配的资源锁。

确定模块1020基于系统资源相匹配的资源锁，确定系统资源的状态信息。

加锁及分配模块1030根据系统资源的状态信息，对系统资源进行加锁，并将加锁后的系统资源分配至容器系统，以用于容器系统对系统资源进行独占访问。

优选地，该装置还包括创建模块，用于为各个系统资源分别创建用于存储其各自已持有的资源锁的第一链表，并为所有资源锁创建一个第二链表；

其中，该装置还包括：

第一更新模块，用于当任一系统资源对应的资源锁的状态信息发生变化时，更新资源锁的第一链表；

第二更新模块，用于基于第一链表的更新信息，更新第二链表。

优选地，监测及确定模块，包括第一确定单元和第二确定单元；第一确定单元用于确定访问请求中与设备对应的系统资源的资源锁标识；第二确定单元用于基于系统资源的资源锁标识，从第二链表中确定与系统资源相匹配的资源锁的状态信息。

优选地，确定模块用于以下任一情形：

1)若与系统资源相匹配的资源锁的状态信息为已被持有，确定系统资源的状态信息为系统资源已被占用。

2)若与系统资源相匹配的资源锁的状态信息为未被持有，确定系统资源的状态信息为系统资源未被占用。

3)若与系统资源相匹配的资源锁的状态信息为不存在，创建系统资源相匹配的资源锁。

优选地，该装置还包括处理类型确定模块；处理类型确定模块用于确定访问请求中与设备对应的系统资源的处理类型。

优选地，当系统资源的状态信息为已被占用，加锁及分配模块用于以下任一情形：

1)当处理类型为加锁时，等待直至系统资源被释放，获取系统资源，并对系统资源进行加锁。

2)当处理类型为尝试加锁时，返回加锁失败提示信息。

3)当处理类型为定时加锁时，在定时加锁的预定时长内等待系统资源被释放，若获取到系统资源，对系统资源进行加锁；若等待时长超过定时加锁的预定时长，返回加锁失败提示信息。

优选地，加锁及分配模块还用于当系统资源的状态信息为未被占用，获取系统资源，并对系统资源进行加锁。

优选地，系统资源的处理类型还包括解锁，该装置还包括第一资源锁确定模块和第一解锁模块；第一资源锁确定模块用于基于系统资源的资源锁标识，确定与系统资源相匹配的资源锁是否存在于第一链表中；第一解锁模块用于若存在，对系统资源进行解锁。

优选地，若与系统资源相匹配的资源锁不存在于第一链表中，该装置还包括第二资源锁确定模块、判断模块和第二解锁模块；第二资源锁确定模块用于基于系统资源的资源锁标识，确定与系统资源相匹配的资源锁是否存在于第二链表中；判断模块用于若与系统资源相匹配的资源锁存在于第二链表中，判断系统资源相匹配的资源锁是否被访问请求持有；第二解锁模块用于若是，对系统资源进行解锁。

本发明实施例提供的多容器系统间共享系统资源的装置可以实现上述提供的方法实施例，具体功能实现请参见方法实施例中的说明，在此不再赘述。

本技术领域技术人员可以理解，本发明包括涉及用于执行本申请中所述操作中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随即存储器)、EPROM(Erasable Programmable Read-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically Erasable Programmable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。