CN102754079A - 多核处理器系统、控制程序、以及控制方法 - Google Patents

多核处理器系统、控制程序、以及控制方法 Download PDF

Info

Publication number
CN102754079A
CN102754079A CN2010800632389A CN201080063238A CN102754079A CN 102754079 A CN102754079 A CN 102754079A CN 2010800632389 A CN2010800632389 A CN 2010800632389A CN 201080063238 A CN201080063238 A CN 201080063238A CN 102754079 A CN102754079 A CN 102754079A
Authority
CN
China
Prior art keywords
thread
cpu
core
polycaryon processor
application program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN2010800632389A
Other languages
English (en)
Inventor
山下浩一郎
山内宏真
宫崎清志
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of CN102754079A publication Critical patent/CN102754079A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Abstract

在多核处理器系统中，应用程序A、C、D处于执行中，并且执行中的应用程序全部都是高可靠性应用程序。向CPU 0分配了应用程序C和应用程序D的高可靠性主线程，向CPU 1分配了应用程序A的高可靠性主线程。当作为主CPU的CPU 0通过调度器(100)接收到作为低可靠性应用程序的应用程序B的低可靠性线程的分配指示时，确定没有被分配高可靠性主线程的CPU。这里，确定为CPU 2和CPU 3，CPU 0通过调度器(100)向所确定的CPU 2通知低可靠性线程的起动指示。由此，以不将高可靠性主线程和低可靠性线程分配给同一个CPU的方式进行了控制。

Description

多核处理器系统、控制程序、以及控制方法
技术领域
本发明涉及进行多核处理器中的主从调度处理和管理程序(hypervisor)处理的多核处理器系统、控制程序、以及控制方法。
背景技术
以往，在多核处理器系统中，已知有被称为分布式系统(以下称为“现有方式1”)和集中共用系统(以下称为“现有方式2”)的方式。
现有方式1是物理上分离的存储器与各个CPU(Central ProcessingUnit，中央处理单元)连接的方式。由此，在现有方式1中，由于分散地连接相互独立的存储器，因此独立的应用程序彼此进行的存取不会冲突，不会发生由于存取冲突引起的CPU的性能下降。因此，即使一个应用程序由于故障而崩溃(crash)，受到影响的也仅仅是当时正在执行该崩溃的应用程序的CPU。
这里，崩溃是指如下状态：在由于含有故障(程序缺陷(bug))的软件将数据写入错误的区域，或者跳转到错误的地址而引起的不能正常动作的状态中，不仅仅是发生故障的软件异常结束，而且由于破坏了系统区域或者进行了错误跳转而导致包含操作系统(OS)的其他的进程不能继续执行的状态。
现有方式2是如下的方式：具有一个物理上的存储器，所有的CPU经由总线等与该存储器连接。现有方式2与现有方式1相比，存储器少因而价格低廉并且消耗功率低，因此在嵌入式系统中采用了现有方式2。在现有方式的主CPU进行的调度中，例如，按照从负载小的CPU开始的顺序来分配应用程序或者由应用程序启动的线程。
另外，在大型计算机等中包括如下机构(现有技术1)，其提供检查点/重启动方法等，为应对崩溃时而保存应用程序的动作状态，在发生了问题时从检查点恢复。
另外，在大型计算机等中，已知有包含OS的软件通过虚拟机对硬件进行存取的方法(现有技术2，例如，参照下述专利文献1～3)。通常虚拟机通过虚拟化来隔离CPU和软件的捆绑，被用于实现平滑的迁移(migration)(向移动目标移动每个虚拟机)。在一个软件由于故障而崩溃的情况下，当机的是当时运行崩溃的软件的虚拟机。
现有技术文献
专利文献
专利文献1：国际公开第2006/134691号小册子；
专利文献2：日本专利文献特开2002-202959号公报；
专利文献3：日本专利文献特开2008-152594号公报。
发明内容
发明所要解决的问题
但是，一直以来，崩溃可能性低的高可靠的应用程序和崩溃可能性高的非高可靠的应用程序被同时执行。由此，存在以下问题：高可靠的应用程序由于受到非高可靠的应用程序引起的崩溃的影响而崩溃。
如果现有技术1以及2，虽然能够防止高可靠的应用程序崩溃，但是在现有技术1以及2中，需要庞大的存储器资源，在存储器资源少的嵌入式系统中难以应用现有技术1以及2。
本发明的目的在于为了解决上述问题，提供能够避免崩溃可能性高的应用程序崩溃的影响波及崩溃可能性低的应用程序的多核处理器系统、控制程序、以及控制方法。
用于解决问题的手段
为了解决上述问题并达到目的，多核处理器系统包括多核处理器和针对每个应用程序软件存储与动作相关的可靠度的存储装置，所述应用程序软件在以下称为“应用程序”，其中，所述多核处理器内的一个核心能够访问所述存储装置，其中，所述一个核心从所述存储装置中提取所述应用程序之中起动对象线程的对象应用程序的可靠度，并基于所提取的可靠度与指定阈值来判断所述对象应用程序是否是高可靠的应用程序，在判断出是所述高可靠的应用程序时，确定所述多核处理器之中的没有被分配非高可靠的应用程序的线程的核心，在判断出是所述非高可靠的应用程序时，确定所述多核处理器之中的没有被分配所述高可靠的应用程序的线程的核心，并向所确定的核心通知所述对象线程的起动指示。
发明的效果
根据本多核处理器系统、控制程序、以及控制方法，能够达到避免崩溃可能性高的应用程序崩溃的影响波及崩溃可能性低的应用程序的效果。
附图说明
图1是示出实施方式1涉及的控制处理的一个实施例的说明图；
图2是示出可靠度列表的一个例子的说明图；
图3是示出任务构成信息的一个例子的说明图；
图4是示出多核处理器系统的硬件构成的框图；
图5是示出实施方式1涉及的多核处理器系统的功能的构成的框图；
图6是示出分配高可靠性线程的例子的说明图；
图7是示出高可靠性线程分配后的任务构成信息的一个例子的说明图；
图8是示出分配低可靠性线程的例子的说明图；
图9是示出没有向所有的CPU 0～3都分配低可靠性线程的例子的说明图；
图10是示出没有向主CPU分配低可靠性线程的例子的说明图；
图11是示出实施方式1涉及的多核处理器系统进行的控制处理的控制处理步骤的一个例子的流程图；
图12是示出图11中所示的高可靠性主线程的分配处理(步骤S1107)的详细的说明的流程图；
图13是示出图11中所示的低可靠性线程的分配处理(步骤S1109)的详细的说明的流程图；
图14是示出多核处理器系统进行的注册处理的注册处理步骤的一个例子的流程图；
图15是示出实施方式2涉及的控制处理的一个实施例的说明图；
图16是示出实施方式2涉及的多核处理器系统的功能的构成的框图；
图17是示出线程崩溃的例子的说明图；
图18是示出各CPU向CPU 0发送存活信号的例子的说明图；
图19是示出应用程序被停止的例子的说明图；
图20是示出重启指示例以及线程的分配指示例的说明图；
图21是示出可靠度列表的可靠度被改变的例子的说明图；
图22是示出向除了停转的CPU之外的剩余的CPU分配崩溃的线程的例子的说明图；
图23是示出再起动后的任务构成信息的一个例子的说明图；
图24是示出向停转的CPU通知线程的起动指示的例子的说明图；
图25是示出实施方式2涉及的多核处理器系统进行的控制处理的控制处理步骤的一个例子的流程图；
图26是示出图25所示的再起动处理(步骤S2503)的详细说明的流程图；
图27是示出图25所示的再起动处理(步骤S2504)的详细说明的流程图；
图28是示出多核处理器进行的发送存活信号处理步骤的一个例子的流程图。
具体实施方式
详细说明根据本发明的多核处理器系统、控制程序、以及控制方法的优选的实施方式。
首先，在实施方式1中，对向各CPU的分配进行说明。接着，在实施方式2中，对在CPU停转(stall)的情况下，由于CPU的停转而崩溃的线程的再起动进行说明。
这里，线程是如公知的那样在应用程序内被执行的处理的执行单位。并且，进程是含有至少一个以上的线程的执行单位。只含有一个线程的进程实质上是线程。由此，在实施方式1中，分配的对象是线程还是进程对由调度器100进行的控制处理没有区别，因此全部使用线程进行说明。
在实施方式1中，将通过被通知来自用户的应用程序的起动指示而被起动的最开始的处理统称为主线程。而且，在实施方式1中，由该主线程新起动的处理称为从线程，在实施方式1中，由从线程新起动的处理也同样地称为从线程。
此外，在主线程中管理所有的诸如从线程的父子关系以及通过处理完成的线程获得的结果等，因此当主线程崩溃时，应用程序将再起动。
以下参照附图详细说明实施方式1以及实施方式2。
(实施方式1)
图1是示出实施方式1涉及的控制处理的一个实施例的说明图。在图1中假设应用程序A、C、D已经在执行中，而且，调度器100接收了应用程序B的线程的分配指示。假设应用程序A、C、D是高可靠的应用程序，应用程序B是非高可靠的应用程序。
这里，对高可靠的应用程序和非高可靠的应用程序进行详细地说明。如上所述高可靠的应用程序是崩溃可能性低的应用程序。例如，高可靠的应用程序是出货时安装的应用程序或者出货单位发布的应用程序。
另一方面，如上所述非高可靠的应用程序是崩溃可能性高的应用程序。例如，非高可靠的应用程序是在应用后用户随意安装的应用程序。
在实施方式1中，高可靠的应用程序称为高可靠性应用程序，高可靠性应用程序的线程称为高可靠性线程。高可靠性线程之中的主线程称为高可靠性主线程，高可靠性线程之中的从线程称为高可靠性从线程。
而且，在实施方式1中，非高可靠的应用程序称为低可靠性应用程序，低可靠性应用程序的线程称为低可靠性线程。低可靠性线程之中的主线程称为低可靠性主线程，低可靠性线程之中的从线程称为低可靠性从线程。
在图1中，向CPU 0分配了应用程序D的高可靠性主线程和应用程序E的高可靠性主线程，向CPU 1分配了应用程序A的高可靠性主线程。向CPU 2分配了应用程序A的高可靠性从线程。向CPU 3分配了应用程序A起动的高可靠性从线程。
这里，调度器100包含在操作系统中。作为主CPU的CPU 0在通过调度器100接收到线程的分配指示时执行该线程的分配处理。
首先，CPU 0在通过调度器100接收到应用程序B的线程的分配指示时从存储器提取与应用程序B有关的可靠度，并判断应用程序B是否是高可靠性应用程序。这里，应用程序B被判断为低可靠性应用程序。
然后，例如，CPU 0通过调度器100确定在CPU 0～3之中没有分配高可靠性主线程的CPU。这里，向CPU 0和CPU 1分配了高可靠性主线程，因此不能向CPU 0和CPU 1分配低可靠性应用程序B的主线程(图1中点线箭头)。
这里，CPU 2和CPU 3被确定为没有分配高可靠性主线程的CPU，例如，向CPU 2分配应用程序B的线程(图1中低可靠性线程)(图1中实线箭头)。
例如，当由于低可靠性线程崩溃而导致CPU 2停转时，被分配给CPU2的高可靠性从线程也同时崩溃。但是，虽然是高可靠性线程但是由于是从线程，因此仅使该崩溃的高可靠性从线程重新执行即可，崩溃的影响不会波及其他的线程。
另外，在图1中，按照是否是高可靠性主线程以及是否是低可靠性线程来划分分配的CPU，但是也可以按照是否是高可靠性线程以及是否是低可靠性线程来划分分配的CPU。由此，在低可靠性线程崩溃的情况下的影响不会影响到高可靠性线程。
(可靠度列表)
图2是示出可靠度列表的一个例子的说明图。可靠度列表200是多核处理器的各个CPU能够访问的存储器中存储的信息，可靠度列表200包括应用程序名201、可靠度项目202。这里，可靠度项目202的值表示可靠度，为了容易理解将可靠度项目202设定为高可靠、低可靠和已崩溃过这3级。对于可靠度可以沿用一直以来所使用的优先度的序号。具体地说，例如，可靠度项目202的值是3时表示是高可靠性应用程序，可靠度项目202的值是2时表示是低可靠性应用程序，可靠度项目202的值是1时表示曾发生过崩溃的已崩溃过的应用程序。
另外，在多核处理器系统的运用设计时，设计者，例如预先将与集成的应用程序有关的可靠度注册到可靠度列表200中。
(任务构成信息)
图3是示出任务构成信息的一个例子的说明图。任务构成信息300是多核处理器的各个CPU能够访问的存储器中存储的信息，在任务构成信息中记述了与执行中的应用程序有关的信息。所谓与应用程序有关的信息是表示应用程序是否是高可靠性应用程序的可靠度标志和表示应用程序的各个线程被分配给了哪个CPU的分配信息。
在任务构成信息300中，通过“TASK_NAME”(任务名)的赋值语句示出了任务名和可靠度标志。这里，任务是如公知的那样表示一个应用程序进行的整个作业。在任务构成信息300中，记述了TASK_FOO和TASK_XYZ，TASK_FOO是与应用程序A有关的信息，TASK_XYZ是与应用程序B有关的信息。
而且，在任务构成信息300中，通过“MASTER”的赋值语句示出了主线程的分配信息。在TASK_FOO中记述了主线程被分配给CPU 0的情形。而且，在任务构成信息300的TASK_FOO中，在“MASTER”赋值语句之下记述了从线程的分配信息。记述了从线程1调用“LIB_BAR”，并且被分配给了CPU 0，从线程2调用“LIB_BUZ”，并且被分配给了CPU 1。这里，“LIB_BAR”和“LIB_BUZ”是函数的名称。
而且，在任务构成信息300的TASK_FOO中，记述了从线程3是进行从0到200执行相同的处理的循环处理中的从0到100的循环处理的线程，从线程3被分配给了CPU 2。
而且，在任务构成信息300的TASK_FOO中，进行从0到200执行相同的处理的循环处理中的从101到200的循环处理线程被分配给了CPU2。
这里，对任务构成信息300内记述的COARSEGRAIN和MIDDLEGRAIN进行说明。在实施方式1中，将调用函数并执行调用的函数的线程称为粗粒度的线程，将执行循环处理的线程称为中粒度的线程。而且，以COAESEGRAIN表示的线程是粗粒度的线程，以MIDDLEGRAIN表示的线程是中粒度的线程。
另外，在TASK_XYZ中，记述了主线程被分配给CPU 1，从线程被分配给了CPU 1。而且，在任务构成信息300中示出了该从线程调用并执行“LIB_BAR”。
(多核处理器系统的硬件构成)
图4是示出多核处理器系统的硬件构成的框图。在图4中，多核处理器系统400包括CPU 0～CPU n(n≥1)、存储器401、以及I/F(Interface，接口)402。另外，各构成部分通过总线400分别连接。
这里，多核处理器是搭载有多个核心的处理器。如果搭载有多个核心，那么既可以是搭载有多个核心的单个处理器，也可以是排列有单核心的处理器的处理器组。此外，在实施方式1中，为了简化说明，以排列有单核心的处理器的处理器组为例进行说明。
存储器401是共享存储器，其中存储有应用程序软件和系统软件(具体地说，管理程序(hypervisor)0～管理程序n、包含调度器100的OS0以及OS1)等程序。存储器401还存储有上述的可靠度列表200和任务构成信息300等系统文件。存储器401具体地说包括ROM(Read OnlyMemory，只读存储器)、RAM(Random Access Memory，随机存取存储器)以及闪速只读存储器等。
在本实施方式1中，假设n＝3总计包括4个CPU。而且，CPU 0～3包括能够独立工作的核心、高速缓存和寄存器等。
CPU 0是负责多处理器系统的整体的控制的主CPU，CPU 1～CPU 3是从CPU。例如，ROM存储上述程序等，RAM被作为CPU 0～3的工作区域使用。存储在存储器401中的程序通过被加载到CPU，使CPU执行被编码在其中的处理。
CPU 0加载管理程序0和包含调度器100的OS0，并执行被编码在它们中的处理。CPU 1加载管理程序1和OS1，并执行被编码在它们中的处理。
CPU 2加载管理程序2和OS1，并执行被编码在它们中的处理。CPU3加载管理程序3和OS1，并执行被编码在它们中的处理。
这里，CPU 1～3分别通过管理程序1～3执行管理程序处理，由此能够执行相同的OS1的处理。另外，CPU 0～3在接收到线程的起动指示时通过OS生成该线程。
管理程序0～3是在CPU 0～3等硬件上直接动作的程序。这里，通常的管理程序处理是对一般的程序无法操作的诸如进行CPU的高速缓存控制以及I/O操作的特殊寄存器进行操作，或者，使用同样地一般的程序无法读写的共享存储器上的空间来进行动作的处理。
另外，CPU 1～3在通过管理程序1～3执行上述的通常的管理程序处理之前，CPU 1～3分别向管理程序0发送表示没有停转的信息。是否停转通过程序计数器是否正常地动作来判断。另外，停转的CPU不能发送表示没有停转的信息。这里，将停转的CPU称为停转CPU。
然后，CPU 0在通过管理程序0执行上述的通常的管理程序处理之前接收从管理程序1～3发送来的表示没有停转的信息来检测停转的CPU。接着，在检测到停转CPU的情况下，执行确定因停转CPU而崩溃的线程的处理，并执行通常的管理程序处理。另一方面，在没有检测到停转CPU的情况下，执行通常的管理程序处理。
I/F 402通过通信线路与LAN(Local Area Network，局域网)、WAN(Wide Area Network，广域网)、互联网等网络403连接，并经由该网络403与其他的装置连接。而且，I/F 402充当网络403与内部的接口，控制来自外部装置的数据的输入输出。对于I/F 402能够采用例如调制解调器或者LAN适配器等。
另外，虽然未图示，在多核处理器系统400中包括显示器以及键盘等。显示器显示光标、图标或者工具箱，以及文件、图像，功能信息等数据。显示器能够采用例如CRT、TFT液晶显示器、等离子显示器等。
键盘包括用于输入文字、数字、各种指示等的键来进行数据的输入。另外，还可以是触摸屏式的输入面板或者数字键盘等。
(实施方式1涉及的多核处理器系统的功能的构成)
图5是示出实施方式1涉及的多核处理器系统的功能的构成的框图。多核处理器系统500的构成包括：接收部501、提取部502、可靠度判断部503、确定部504、检测部505、分配判断部506、决定部507、以及通知部508。各功能(接收部501～通知部508)通过，具体地说，例如，作为主CPU的CPU 0执行如图4所示的存储器401所存储的、被编码在调度器100中的处理来实现。
(线程起动时相关的处理)
首先，接收部501接收线程或者进程的起动指示。具体地说，例如，作为主CPU的CPU 0接收来自用户的应用程序的起动指示。或者，正在执行中的线程新建立线程时，CPU 0从正在执行中的线程接收线程的起动指示。
接着，提取部502基于应用程序名201从可靠度列表200提取对象应用程序的可靠度，所述对象应用程序起动由接收部501接收的对象线程。
然后，可靠度判断部503基于由提取部502提取的可靠度和指定阈值来判断对象应用程序是否是高可靠性应用程序。具体地说，例如，如果可靠度在指定阈值以上那么就判断对象应用程序是高可靠性应用程序，如果小于指定阈值那么就判断对象应用程序是低可靠性应用程序。
确定部504在由可靠度判断部503判断为是高可靠性应用程序的情况下，确定所有的CPU 0～3之中没有分配低可靠性线程的CPU。
这里，没有分配低可靠性线程的CPU是指分配了高可靠性线程的核心或者没有分配任何线程的CPU。
确定部504在由可靠度判断部503判断为是低可靠性应用程序的情况下，确定多核处理器之中没有分配高可靠性线程的CPU。
这里，没有分配高可靠性线程的CPU是指分配了低可靠性线程的核心或者没有分配任何线程的CPU。
然后，通知部508向由确定部504确定的核心通知对象线程的起动指示。
另外，确定部504在由可靠度判断部503判断对象应用程序是低可靠性应用程序的情况下，确定多核处理器之中没有分配低可靠性应用程序的主线程的核心。
另外，确定部504在由可靠度判断部503判断为是高可靠性应用程序的情况下，仅在对象线程是主线程的情况下确定多核处理器之中没有分配低可靠性线程的CPU。
在由可靠度判断部503判断对象应用程序是高可靠性应用程序的情况下，当对象线程是高可靠性主线程时，通知部508向由确定部504确定的CPU通知对象线程的起动指示。另一方面，当对象线程不是高可靠性主线程时，通知部508向多核处理器中的任意的CPU通知对象线程的起动指示。所谓对象线程不是高可靠性主线程是指对象线程是高可靠性从线程。
基于以上的情况，使用附图来说明分配例子。
图6是示出分配高可靠性线程的例子的说明图。具体地说，例如，首先，在用户指示起动应用程序A时，CPU 0接收应用程序A的主线程的分配指示。此外，这里，假设所有的CPU 0～3都没有分配任何线程。虽然未图示，假设在这时任务构成信息中也没有记述任何信息。
然后，具体地说，例如，CPU 0访问优先度列表200，基于应用程序名201来提取可靠度项目202的值。这里，应用程序A的可靠度项目202的值是3。
接着，具体地说，例如，CPU 0判断应用程序A的可靠度是否在指定阈值以上。在实施方式1中，指定阈值是3。然后，例如，当由CPU 0判断应用程序A的可靠度在指定阈值以上时，应用程序A被判断为高可靠性应用程序。另一方面，例如，当由CPU 0判断应用程序A的可靠度小于指定阈值时，应用程序A被判断为低可靠性应用程序。这里，应用程序A的可靠度项目202的值是3，因此应用程序A被判断为高可靠性应用程序。
接着，具体地说，例如，在应用程序A被判断为是高可靠性应用程序的情况下，CPU 0基于任务构成信息确定在CPU 0～3之中没有被分配低可靠性线程的CPU。
例如，CPU 0针对任务构成信息内记述的每个与应用程序相关的信息判断可靠度标志是否是1。上述的与应用程序相关的信息是指表示是否是高可靠性应用程序的可靠度标志和表示应用程序的线程被分别分配给哪个CPU的分配信息。
然后，CPU 0确定与可靠度标志被判断为0的应用程序相关的信息内记述的CPU。被确定的CPU是分配了低可靠性线程的CPU。
然后，例如，CPU 0将CPU 0～3中除了分配了低可靠性线程的CPU之外的CPU确定为没有分配低可靠性线程的CPU。这里，所有的CPU0～3被确定为没有分配低可靠性线程的CPU。
然后，例如，CPU 0向CPU 0～3中的一个通知主进程的起动指示。在存在多个没有分配低可靠性线程的CPU的情况下，对于分配给哪个CPU与现有的分配处理是相同的，因此省略详细的说明。这里，通知CPU0(图中(1))。然后，CPU 0起动主进程。
而且，例如，在向CPU 0通知起动指示之前，CPU 0访问存储器401向任务构成信息中新追加与应用程序A相关的信息。例如，记述任务名和可靠度标志。然后，在与该应用程序A相关的信息内记述与主线程分配给了哪个CPU相关的分配信息。
接着，当CPU 0通过调度器100接收到来自高可靠性主线程的高可靠性从线程的分配指示时，该高可靠性主线程被分配给CPU 0～3中任意的CPU。由此，假设高可靠性从线程被如图中(2)～(5)那样分配。
图7是示出高可靠性线程分配后的任务构成信息的一个例子的说明图。任务构成信息700中仅仅记述了“TASK_FOO”。“TASK_FOO”是与上述的任务构成信息300同样的与应用程序A相关的信息。此外，任务构成信息700只是没有记述上述的任务构成信息300的“TASK_XYZ”，对“TASK_FOO”的记述是相同的，因此这里省略详细的说明。
接着，图8是示出分配低可靠性线程的例子的说明图。这里，假设通过用户的操作通知了应用程序B的起动指示，并仅说明与上述的高可靠性应用程序的分配例子的不同点。
接着，具体地说，例如，CPU 0判断应用程序B的可靠度是否在指定阈值以上。这里，在可靠度列表200中，应用程序B的可靠度项目202的值是2，因此应用程序B被判断为是低可靠性应用程序。
接着，具体地说，例如，在应用程序B被判断为是低可靠性应用程序的情况下，CPU 0基于任务构成信息700确定CPU 0～3之中没有分配高可靠性主线程的CPU。
例如，CPU 0针对任务构成信息700内记述的每个与应用程序相关的信息判断可靠度标志是否是1。例如，CPU 0确定在与可靠度标志是1的应用程序相关的信息中的MASTER赋值语句所记述的CPU。被确定的CPU是分配了高可靠性主线程的CPU。然后，例如，CPU 0将CPU 0～3中除了分配了高可靠性主线程的CPU之外的剩余的CPU确定为没有分配高可靠性主线程的CPU。
这里，由于“TASK_FOO”的主进程被分配给了CPU 0，因此CPU1～3被确定为没有分配高可靠性应用程序的主进程的CPU。
然后，例如，CPU 0向CPU 1～3中的一个通知低可靠性主线程的起动指示。这里，通知给CPU 1(图中(6))。然后，CPU 1起动低可靠性主线程。
而且，例如，在向CPU 1通知起动指示之前，CPU 0访问存储器401并向任务构成信息700中追加与应用程序B相关的信息，记述与主线程被分配给了哪个CPU相关的信息。此外，图3的任务构成信息300是向任务构成信息700追加了与应用程序B相关的信息后的例子。
接着，当从应用程序B的低可靠性主线程通知低可靠性从线程的分配指示时，CPU 0接收分配指示，再次进行同样的处理。由此，如图8中的(7)那样分配低可靠性从线程。
返回到图5的说明，检测部505确定由确定部504确定的CPU中的没有被分配任何线程的CPU。
分配判断部506在对检测部505所检测出的CPU分配了对象线程的情况下，判断是否对多核处理器的所有的CPU 0～3都分配了高可靠性主线程。
然后，决定部507在由分配判断部506判断为向所有的CPU 0～3都已经分配了高可靠性主线程的情况下，从由确定部504确定的CPU中除由检测部505检测出的CPU之外的剩余的CPU中决定分配对象线程的CPU。
接着，通知部508向由决定部507决定的CPU通知对象线程的分配指示。
另外，分配判断部506在向由检测部505检测出的CPU分配了对象线程的情况下，判断是否向所有的CPU 0～3都分配了低可靠性线程。
然后，决定部507在由分配判断部506判断为向所有的CPU都分配了低可靠性线程的情况下，从由确定部504确定的CPU中除由检测部505检测出的CPU之外的剩余的CPU中决定分配对象线程的CPU。
接着，通知部508向由决定部507决定的CPU通知对象线程的分配指示。
这里，基于上述的处理，使用附图来进行说明。
图9是示出没有向所有的CPU 0～3都分配低可靠性线程的例子的说明图。这里，例如，假设应用程序B的低可靠性主线程、低可靠性从线程1、以及低可靠性从线程2已经被分配。此外，未图示任务构成信息。而且，假设向CPU 0新通知了来自低可靠性主线程的低可靠性从线程3的分配指示。
具体地说，例如，CPU 0针对任务构成信息内记述的每个与应用程序相关的信息判断可靠度标志是否是1。确定与可靠度标志被判断为1的应用程序相关的信息内所记述的CPU。这里，确定为CPU 0。
然后，例如，CPU 0在CPU 0～3之中确定与可靠度标志是1的应用程序相关的信息内所记述的CPU。被确定的CPU是分配了高可靠性线程的CPU。接着，确定所有的CPU 0～3之中除了分配了高可靠性线程的CPU之外的CPU为没有分配高可靠性线程的CPU。这里，CPU 0～3都被确定为没有分配高可靠性线程的CPU。
然后，例如，CPU 0进一步确定与可靠度标志是0的应用程序相关的信息内所记述的CPU。被确定的CPU是分配了低可靠性线程的线程。接着，例如，CPU 0确定没有分配高可靠性线程的CPU之中除了被分配了低可靠性线程的CPU之外的剩余的CPU。所确定的CPU是没有被分配任何的线程的CPU。这里，不存在已经分配了高可靠性线程的CPU，并向CPU 0～2分配了低可靠性线程，因此CPU 3被确定为没有分配任何线程的CPU。
然后，例如，CPU 0通过向CPU 3分配对象线程，来判断是否向CPU0～3中的每一个CPU都分配了低可靠性线程。具体地说，例如，CPU 0判断分配有低可靠性线程的CPU数目与没有分配任何线程的CPU数目的总和是否达到所有的CPU的数目。
如果总和值达到所有的CPU的数目，则CPU 0通过向没有分配任何线程的CPU 3分配对象线程而判断出向所有的CPU 0～3都分配了低可靠性线程。如果总和值没有达到所有的CPU的数目，则CPU 0通过向没有分配任何线程的CPU 3分配对象线程而判断出没有向所有的CPU 0～3都分配了低可靠性线程。
这里，所有的CPU的数目是4个，已经分配了低可靠性线程的CPU的数目是3个，没有分配任何线程的CPU的数目是1个。因此，通过向CPU 3分配对象线程而判断出向CPU 0～3中的每一个CPU都分配了低可靠性线程。
接着，具体地说，例如，CPU 0在判断为向每个CPU都分配了低可靠性线程的情况下，从CPU 0～3之中除CPU 3之外的剩余的CPU中决定分配对象线程的CPU。这里，剩余的CPU是CPU 0～2。这里，CPU 1被决定为分配的CPU。
然后，具体地说，例如，CPU 0向决定的CPU 1通知对象线程的起动指示。在图9中，低可靠性从线程3被新分配给CPU 1。
另外，不向所有的CPU 0～3都分配高可靠性主线程而进行的控制处理与不向所有的CPU 0～3都分配低可靠性线程而进行的控制的处理是相同的，因此省略详细的说明。
返回到图5，在由可靠度判断部503判断为是低可靠性应用程序的情况下，确定部504从所有的CPU 0～3之中除了作为主CPU的CPU 0之外的剩余的CPU中确定没有分配高可靠性线程的CPU。
然后，通知部508向由确定部504确定的CPU通知对象线程的起动指示。因此，必定不会向作为主CPU的CPU 0分配低可靠性线程。
图10是示出没有向主CPU分配低可靠性线程的例子的说明图。这里，还是假设向CPU 2～3分别分配了低可靠性线程，例如，假设CPU 0接收到低可靠性线程的分配通知。此外，图10的低可靠性线程表示低可靠性主线程以及低可靠性从线程。
然后，例如，CPU 0从CPU 0～3之中除了CPU 0之外的CPU中确定没有分配高可靠性线程的CPU。这里，CPU 1～3被确定为没有分配高可靠性线程的CPU。然后，例如，CPU 0向CPU 1通知低可靠性线程的起动指示(图10中实线箭头)。
因此，由于不会向CPU 0分配崩溃可能性高的低可靠性线程(图10中虚线箭头)，因此CPU 0停转的可能性降低。
另外，虽然未图示，但是例如可以：CPU 0预先以不向CPU 0和CPU1分配低可靠性线程的方式进行控制，以不向CPU 2和CPU 3分配高可靠性主线程的方式进行控制。
返回到图5，提取部502进一步提取与对象应用程序是否已崩溃过相关的信息。
然后，可靠度判断部503判断与对象应用程序是否已崩溃过相关的信息是否表示已崩溃过。
然后，在表示是已崩溃过的情况下，通知部508可以不向任何CPU通知对象线程的起动指示，而向用户通知对象应用程序已崩溃过所以不能起动。
另一方面，在由可靠度判断部503判断为不是已崩溃过的情况下，确定部504实施上述的处理。由此，能够不使崩溃过的应用程序起动。
具体地说，例如，CPU 0在接收到线程的分配指示时，读出可靠度列表200，并判断优先度项目202的值是否是1。然后，CPU 0在判断优先度项目202的值是1的情况下，不向任何CPU通知线程的起动指示，并输出对象应用程序是已经停转(stall)的。作为输出形式，例如有在显示器上显示、通过I/F 402向外部装置发送。
另外，在本实施方式1中，基于对象应用程序是否是高可靠性应用程序来决定分配的CPU，进一步，还可以详细地分割可靠度如对象应用程序是高可靠性应用程序、低可靠性应用程序、中可靠性应用程序等来决定分配的CPU。
(多核处理器系统进行的控制处理的控制处理步骤)
图11是示出实施方式1涉及的多核处理器系统进行的控制处理的控制处理步骤的一个例子的流程图。首先，CPU 0判断是否通过调度器100接收到了对象线程的分配指示(步骤S1101)，在判断为没有接收到的情况下(步骤S1101：否)，返回到步骤S1101。另一方面，CPU 0在判断通过调度器接收到了对象线程的分配指示的情况下(步骤S1101：是)，读出可靠度列表(步骤S1102)。
接着，CPU 0通过调度器100从可靠度列表200中提取起动线程的对象应用程序的可靠度(步骤S1103)，并判断对象应用程序是否发生过停转(stall)(步骤S1104)。然后，CPU 0在通过调度器100判断为没有发生过停转的情况下(步骤S1104：否)，判断对象应用程序是否是高可靠的应用程序(步骤S1105)。
首先，CPU 0在通过调度器100判断为对象应用程序是高可靠的情况下(步骤S1105：是)，判断对象线程是否是主线程(步骤S1106)。然后，CPU 0在通过调度器100判断为对象线程是主线程的情况下(步骤S1106：是)，实施高可靠性主线程的分配处理(步骤S1107)。
另一方面，CPU 0在通过调度器100判断对象线程不是主线程的情况下(步骤S1106：否)，向任意的CPU通知对象线程的起动指示(步骤S1108)。
接着，在步骤S1105中，CPU 0在通过调度器100判断对象应用程序是非高可靠的应用程序的情况下(步骤S1105：否)，实施低可靠性线程的分配处理(步骤S1109)。
在步骤S1107、步骤S1108、或者步骤S1109之后，CPU 0通过调度器100向任务构成信息追加对象线程的分配信息(步骤S1110)，结束一系列的处理。
另一方面，在步骤S1104中，CPU 0在通过调度器100判断为发生过停转的情况下(步骤S1104：是)，向用户通知发生过停转(步骤S1111)，结束一系列的处理。
接着，图12是示出图11中所示的高可靠性主线程的分配处理(步骤S1107)的详细的说明的流程图。首先，CPU 0通过调度器100读出任务构成信息(步骤S1201)，并确定没有分配低可靠性线程的CPU(步骤S1202)。然后，CPU 0从通过调度器100确定的CPU中检测出没有分配线程的CPU(步骤S1203)。
然后，判断是否向多核处理器中的各个CPU都分配了高可靠性主线程(步骤S1204)。
CPU 0在通过调度器100判断为向各个CPU都分配了高可靠性主线程的情况下(步骤S1204：是)，从确定的CPU之中除检测出的CPU之外的剩余的CPU中决定分配对象线程的CPU(步骤S1205)。关于决定方法，与现有的调度处理是相同的，因此省略详细的说明。
另一方面，CPU 0在通过调度器100判断为没有向各个CPU都分配了高可靠性主线程的情况下(步骤S1204：否)，从确定的CPU中决定分配对象线程的CPU(步骤S1206)。
然后，在步骤S1205或者步骤S1206之后，CPU 0通过调度器100向决定的CPU通知对象线程的起动指示(步骤S1207)，转移到步骤S1110。
另一方面，CPU 0在通过调度器100判断为没有向各个CPU都分配了高可靠性主线程的情况下(步骤S1204：否)，转移到步骤S1206。
接着，图13是示出图11中所示的低可靠性线程的分配处理(步骤S1109)的详细的说明的流程图。首先，CPU 0通过调度器100读出任务构成信息(步骤S1301)，并确定没有分配高可靠性主线程的CPU(步骤S1302)。然后，CPU 0从通过调度器100确定的CPU中检测出没有被分配线程的CPU(步骤S1303)，通过向所检测出的CPU分配对象线程来判断是否向各个CPU都分配了低可靠性主线程(步骤S1304)。
然后，CPU 0在通过调度器100判断为向各个CPU都分配了低可靠性线程的情况下(步骤S1304：是)，从确定的CPU之中除检测出的CPU之外的剩余的CPU中决定分配对象线程的CPU(步骤S1305)。
另一方面，CPU 0在通过调度器100判断为没有向各个CPU都分配了低可靠性线程的情况下(步骤S1304：否)，从确定的CPU中决定分配对象线程的CPU(步骤S1306)。然后，CPU 0通过调度器100向所选择的CPU通知对象线程的起动指示(步骤S1306)，转移到1110。
另外，CPU 0通过OS在下载或者安装应用程序时提取优先度，向可靠度列表注册应用程序名，将所提取的优先度作为可靠度进行注册。
(多核处理器系统的注册处理步骤)
图14是示出多核处理器系统进行的注册处理的注册处理步骤的一个例子的流程图。这里，示出CPU 0通过OS向可靠度列表注册可靠度的注册处理步骤。首先，CPU 0通过OS0下载应用程序(步骤S1401)，并提取优先度标签(tag)(步骤S1402)。然后，CPU 0通过OS0读取可靠度列表(步骤S1403)，并注册应用程序的可靠度(步骤S1404)。优先度标签是例如表示出货单位等的标签，如果出货单位是多核处理器的设计单位，则在可靠度列表中将应用程序的可靠度注册为高可靠。
(实施方式2)
接着，图15是示出实施方式2所涉及的控制处理的一个实施例的说明图。在实施方式2中，示出立即再起动因停转的停转CPU而崩溃的线程的例子。这里，停转CPU是程序计数器不再动作、不能再执行软件处理的CPU。首先，CPU 0通过管理程序0检测出停转的停转CPU(图15中(1))。这里，CPU 1被作为停转CPU检测出。
接着，通过停转CPU确定崩溃的线程(图15中(2))。这里，高可靠性从线程2是被确定的线程。最后，CPU 0通过管理程序0将确定的线程的分配指示通知给调度器100(图15中(3))。
然后，CPU 0通过调度器100将高可靠性从线程分配给CPU 1、CPU2以及CPU 3中的任一个
这里，说明与恢复处理相关的问题。当使用现有技术1以及2时，为了保存动作状态需要确保存储器以及线程的状态，在嵌入式系统中，存储器的资源少，因此难以确保资源。由此，存在为了确保资源而系统变得庞大的问题。
因此，在实施方式2中，在只有少量存储器资源的规格中，立即再起动因停转的停转CPU而崩溃的线程。在实施方式2中，对于与实施方式1所示的构成的相同的构成标注相同的符号，并省略说明。
(实施方式2涉及的多核处理器系统)
图16是示出实施方式2涉及的多核处理器系统的功能的构成的框图。多核处理器系统1600的构成包括接收部1601、检测部1602、停止通知部1603、删除部1604、确定部1605、重启通知部1606、改变部1607、分配通知部1608、解除通知部1609。具体地说，各功能(接收部1601～解除通知部1609)通过例如CPU 0执行如图4所示的存储器401中所存储的、被编码在管理程序0中的处理来实现。
首先，接收部1601接收从多核处理器中除了一个CPU之外的CPU发送来的表示没有停转的信息。具体地说，例如，接收从通过管理程序1～3执行管理程序处理的CPU 1～3发送来的存活信号。
检测部1602检测多核处理器中的停转CPU。具体地说，例如，CPU 0将多核处理器中的无存活信号的CPU作为停转CPU检测出。这里，在由检测部1602没有检测到停转CPU的情况下，执行通常的管理程序处理。以下，对于由检测部1602检测到停转CPU的情况下的处理进行说明。
首先，在存储器401内分配给停转CPU的一部分存储器被释放。
然后，停止通知部1603向所有的CPU 0～3通知全部应用程序的暂时停止指示。删除部1604从任务构成信息300中删除与起动由检测部1602检测到的导致停转CPU停转的线程的应用程序相关的信息。将导致停转CPU停转的线程称为崩溃线程。
另外，改变部1607将可靠度列表中记述的起动使由检测部1602检测出的停转CPU停转的崩溃线程的应用程序的可靠度改变为表示已崩溃过的可靠度。
接着，确定部1605确定因由检测部1602检测到的停转CPU的停转而崩溃的线程。这里，因停转CPU的停转而崩溃的线程是指：直到停转CPU即将停转之前为止正常地执行处理且由于停转而崩溃的线程。由此，上述的崩溃线程不包含在因停转CPU的停转而崩溃的线程中。具体地说，例如，读出任务构成信息700，根据任务构成信息700确定分配给停转CPU的线程。
然后，重启通知部1606向由检测部1602检测到的停转CPU通知重启指示。具体地说，例如，CPU 0向停转CPU进行复位指示。此外，复位指示是管理程序的特权命令。
然后，分配通知部1608向调度器100通知用于将由确定部1605确定的线程向所有的CPU 0～3中除了停转CPU之外的剩余的CPU分配的线程分配指示。具体地说，例如，CPU 0向CPU 0所具有的寄存器输出表示分配指示的信息。
由此，CPU 0通过调度器100接收到线程分配指示的通知时，执行向多核处理器分配线程的处理。具体地说，例如，CPU 0执行实施方式1所示的处理。
另外，分配通知部1608在停转CPU重启完毕之后向调度器100通知由确定部1605确定的线程的分配指示。
而且，解除通知部1609接收到来自分配通知部1608的线程分配通知，并且当由该调度器100分配了线程时，向CPU 0～3通知解除暂时停止的解除通知。
基于以上的说明，使用附图来说明因停转CPU而崩溃的线程的再起动例子。首先，在实施方式2中，作为崩溃前的例子，例举图9所示的分配结果和图3所示的任务构成信息300来说明。
图17是示出线程崩溃的例子的说明图。假设被分配给CPU 1的低可靠性从线程崩溃，而且，OS1由于崩溃的影响而崩溃了，从而程序计数器停止，导致CPU 1停转。
图17中记载的CPU 0的处理表示由OS0进行的处理和由管理程序0进行的处理，CPU 1的处理表示由OS1进行的处理和由管理程序1进行的处理。CPU 2的处理表示由OS1进行的处理和由管理程序2进行的处理，CPU 3的处理表示由OS1进行的处理和由管理程序3进行的处理。
图18是示出各CPU向CPU 0发送存活信号的例子的说明图。例如，在CPU 0～3没有停转的情况下，CPU 1～3通过各自的管理程序定期地向CPU 0通知表示没有停转的信息。然后，通知后，CPU 1～3通过各自的管理程序实施通常的管理程序处理。
CPU 2和CPU 3分别通过管理程序2和管理程序3向CPU 0发送表示没有停转的信息(以下，称为“存活信号”)(图18中(1))。另一方面，由于CPU 1停转，因此CPU 1不能通过管理程序1向CPU 0发送存活信号。
具体地说，例如，CPU 0通过管理程序0接收来自各CPU的存活信号。然后，CPU 0检测没有发送存活信号的CPU。这里，没有发送存活信号的CPU是停转CPU。
接着，图19是示出应用程序被停止的例子的说明图。具体地说，例如，当检测到停转CPU时，CPU 0通过管理程序0向各CPU通知应用程序的暂时停止指示(图19中(2))。然后，各CPU使通过OS起动的线程全部暂时停止。
然后，具体地说，例如，CPU 0将作为与应用程序B相关的信息的TASK_XYZ的记载全部删除。删除后的任务构成信息是与图7的任务构成信息700相同的。此外，对于作为CPU的停转原因的崩溃的线程的确定，一直历来通过OS是能够做到的，因此省略详细的说明。
接着，图20是示出重启指示例以及线程的分配指示例的说明图。具体地说，例如，CPU 0通过管理程序0向CPU 1通知重启指示(图20中(3))，当CPU 1接收到重启指示时即重启。
而且，具体地说，例如，CPU 0通过管理程序0读出任务构成信息，确定被分配给CPU 1的线程。
图21是示出可靠度列表的可靠度被改变的例子的说明图。具体地说，例如，CPU 0通过管理程序0读出可靠度列表200，并将应用程序B的可靠度项目202的值改为1。改变后的可靠度列表是可靠度列表2100。
然后，图22是示出向除了停转CPU之外的剩余的CPU分配崩溃的线程的例子的说明图。具体地说，例如，CPU 0将通过管理程序0确定的线程的分配指示通知给调度器100(图22中(4))。
然后，在CPU 1处于重启中的情况下，CPU 0通过调度器100向CPU0、CPU 2和CPU 3中的任意的CPU分配所确定的线程。这里，CPU 0通过调度器100向CUP 2通知高可靠性从线程2的起动指示(图22中(5))。然后，CPU 2通过OS1起动高可靠性从线程2。
接着，CPU 0通过管理程序0向各CPU通知暂时停止的解除指示(图22中(6))，各CPU通过OS解除暂时停止。由此，因停转CPU而崩溃的线程被立即再起动。
然后，图23是示出再起动后的任务构成信息的一个例子的说明图。通过调度器100更新任务构成信息，在任务构成信息2300中示出了高可靠性从线程被分配给CPU 2(图23中的下划线部分)。
另外，在CPU 1已经重启完毕的情况下，CPU 0通过调度器100向CPU 0～3中的任意的CPU分配所确定的线程。
返回到图16，另外，分配通知部1608不向调度器100通知分配指示，而将由确定部1605确定的线程的起动指示通知给通过重启通知部1606发出的重启指示而被重启的重启完毕的停转CPU。
图24是示出向停转CPU通知线程的起动指示的例子的说明图。具体地说，例如，CPU 0在CPU 1重启后通过管理程序0向CPU 1通知所确定的线程的起动指示(图24中(1))而不向调度器100通知分配指示。然后，具体地说，例如，CPU 0通过管理程序0向各CPU通知解除应用程序的暂时停止的解除指示(图24中(2))。
具体地说，例如，CPU 0当通过OS0接收到解除指示时，解除所分配的各线程的暂时停止。而且，具体地说，例如，当CPU 2和CPU 3通过OS1接收到解除指示时，解除分配给各CPU的各线程的暂时停止。此外，关于暂时停止处理以及暂时停止的解除处理的具体的处理内容是公知的，因此省略详细的说明。
另外，返回到图16，确定部1605确定因停转CPU而崩溃的线程，并且确定崩溃的线程是中粒度的线程还是粗粒度的线程。然后，确定部1605在崩溃的线程是粗粒度的线程的情况下，确定调用函数和该函数的系数。
另一方面，确定部1605在崩溃的线程是中粒度的线程的情况下，确定崩溃时所执行着的执行位置和结束位置。
然后，分配通知部1608在确定的线程是粗粒度的线程的情况下，同时通知分配通知和与调用函数相关的信息。另一方面，在确定的线程是中粒度的线程的情况下，分配通知部1608同时通知分配通知以及执行位置和结束位置。
具体地说，例如，CPU 0读出任务构成信息，根据任务构成信息来确定崩溃的线程，并且确定崩溃的线程是COARSEGRAIN(粗粒度)还是MIDDLEGRAIN(中粒度)。
然后，具体地说，例如，CPU 0在所确定崩溃的线程是COARSEGRAIN时，确定该线程所调用的调用函数。
另一方面，具体地说，例如，CPU 0在所确定崩溃的线程是MIDDLEGRAIN时，确定该线程所实施着的循环处理的循环序号。而且，具体地说，例如，CPU 0确定任务构成信息所记述的101～200的循环处理中已经执行完毕的循环序号。与执行完毕的循环序号相关的信息通过OS被存储在存储器401或者CPU内的寄存器中。例如，如果在101～200之中1～50已经执行完毕，那么50被存储。
另外，在执行完毕的循环序号的信息被存储在存储器401中的被分配给停转CPU的区域的情况下，在停转CPU被重启之前，CPU 0将执行完毕的循环序号的信息存储到存储器401中的被分配给CPU 0的区域。
然后，具体地说，例如，CPU 0通过管理程序0向调度器100通知崩溃的线程的分配指示和循环处理的循环序号中未执行的循环序号。或者，例如，CPU 0通过管理程序0向重启完毕的CPU 1通知崩溃的线程的起动指示和未执行的循环序号。
(实施方式2涉及的控制处理的控制处理步骤)
图25是示出实施方式2涉及的多核处理器系统进行的控制处理的控制处理步骤的一个例子的流程图。首先，CPU 0通过管理程序0接收存活信号(步骤S2501)，并判断是否从所有的CPU都接收到了存活信号(步骤S2502)。
然后，在CPU 0通过管理程序0判断出没有从所有的CPU接收到存活信号的情况下(步骤S2502：否)，实施再起动处理(步骤S2503或者步骤S2504)。接着，CPU 0通过管理程序实施通常的管理程序处理(步骤S2505)，并结束一系列的处理。另一方面，在CPU 0通过管理程序0判断从所有的CPU都接收到了存活信号的情况下(步骤S2502：是)，向步骤S2505转移。
图26是示出图25所示的再起动处理(步骤S2503)的详细的说明的流程图。首先，确定停转的停转CPU(步骤S2601)，并通知全部应用程序的暂时停止指示(步骤S2602)。然后，向停转CPU通知重启指示(步骤S2603)，并读出可靠度列表(步骤S2604)。
然后，改变崩溃的应用程序的可靠度(步骤S2605)，并读出任务构成信息(步骤S2606)。从任务构成信息中删除与崩溃的应用程序相关的任务信息(步骤S2607)。
接着，根据任务构成信息检测出被分配给停转CPU的线程(步骤S2608)，并且判断是否有未选择的线程(步骤S2609)。
然后，在判断为有未选择的线程的情况下(步骤S2609：是)，从未选择的线程中选择任意的线程(步骤S2610)。然后，判断选择的线程是否是粗粒度(步骤S2611)，在判断为粗粒度时(步骤S2611：是)，确定调用函数(步骤S2612)。
另一方面，在判断为不是粗粒度时(步骤S2611：否)，确定未执行的迭代(iteration)(步骤S2613)。
然后，在步骤S2612或者步骤S2613之后，将在步骤S2612或者步骤S2613中确定的信息和线程的分配指示关联起来通知给调度器(步骤S2614)，并返回到步骤S2609。
另外，在判断为没有未选择的线程时(步骤S2609：否)，通知暂时停止的解除指示(步骤S2615)，转移到步骤S2505。
图27是示出图25所示的再起动处理(步骤S2504)的详细的说明的流程图。图27中所示的步骤S2701～S2713与图26中所示的步骤S2601～S2613是相同的处理，步骤S2716与步骤S2615是相同的处理，因此省略对与图26中所示的处理相同的处理的说明。由此，这里，说明步骤S2714和步骤S2715。
在步骤S2712或者步骤S2713之后，判断停转CPU是否已经重启(步骤S2714)。然后，在没有重启的情况下(步骤S2714：否)，返回到步骤S2714。
在判断为已经重启的情况下(步骤S2714：是)，将在步骤S2712或者步骤S2713中确定的信息和起动指示关联起来通知给重启后的停转CPU(步骤S2715)。
(多核处理器进行的存活信号的发送处理步骤)
图28是示出由多核处理器进行的存活信号的发送处理步骤的一个例子的流程图。首先，在从CPU中没有停转的CPU通过各自的管理程序向主CPU发送存活信号(步骤S2801)，并实施通常的管理程序处理(步骤S2802)。在从CPU停转的情况下，由于不能实施图28中记载的处理，因此存活信号不会被发送给主CPU，从而，主CPU能够检测停转的从CPU。
另外，主CPU通过如实施方式1所示的那样实施向主CPU分配高可靠性主线程的调度处理，从而主CPU不会停转，管理程序处理始终能够动作。
如上所述，根据多核处理器系统、控制程序、以及控制方法，以不向同一个CPU分配高可靠的应用程序的线程和非高可靠的应用程序的线程的方式进行控制。由此，能够防止因非高可靠的应用程序的线程崩溃而导致高可靠的应用程序的线程崩溃。
另外，以不向已经分配了高可靠的应用程序的主线程的CPU分配非高可靠的应用程序的方式进行控制。由此，即使非高可靠的应用程序的线程崩溃，也仅是高可靠的应用程序的从线程有崩溃的可能，能够防止高可靠的应用程序的主线程崩溃。由此，只需要再起动崩溃的从线程即可，使恢复变得容易。
另外，以不向已经分配了非高可靠的应用程序的线程的CPU分配高可靠的应用程序的主线程的方式进行控制。而且，高可靠的应用程序的从线程被分配给多核处理器中的任意的CPU。
通过防止高可靠的应用程序的线程中至少主线程因非高可靠的应用程序而崩溃，能够防止再起动高可靠的应用程序的所有的线程的麻烦。
以不是向多核处理器中的所有的CPU都分配高可靠的应用程序的主线程的方式进行控制。由此，即使在仅有高可靠的应用程序被执行时，也能够向CPU分配非高可靠的应用程序的线程。
以不是向多核处理器中的所有的CPU都分配非高可靠的应用程序的主线程的方式进行控制。由此，即使在仅有非高可靠的应用程序被起动时，也能够向CPU分配高可靠的应用程序的线程。
另外，通过不向主核心分配非高可靠的应用程序的线程，能够防止执行调度处理的主核心停转。
如上所述，根据多核处理器系统、控制程序、以及控制方法，控制调度器使得因停转的停转CPU而崩溃的线程被再起动。由此，即使仅有少量的存储器资源也能够立即再起动崩溃的线程。
另外，通过重启停转CPU，并向重启后的停转CPU通知崩溃的线程的起动指示，能够不经由调度器也能够容易地将崩溃的线程分配给低负载的核心。
符号说明
500、1600多核处理器系统
100调度器
502提取部
503可靠度判断部
504确定部
505检测部
506分配判断部
507决定部
508通知部
1602检测部
1605确定部
1608分配通知部
1606重启通知部

Claims (12)

1.一种多核处理器系统，其特征在于，所述多核处理器系统包括多核处理器、以及针对每个应用程序软件存储与动作相关的可靠度的存储装置，所述应用程序软件在以下称为“应用程序”，其中，所述多核处理器内的一个核心能够访问所述存储装置，
所述一个核心包括：
提取单元，所述提取单元从所述存储装置中提取所述应用程序之中起动对象线程的对象应用程序的可靠度；
可靠度判断单元，所述可靠度判断单元基于所述提取单元所提取的可靠度和指定阈值来判断所述对象应用程序是否是高可靠的应用程序；
确定单元，在所述可靠度判断单元判断出所述对象应用程序是所述高可靠的应用程序时，所述确定单元确定所述多核处理器之中的没有被分配非高可靠的应用程序的线程的核心，而在所述可靠度判断单元判断出所述对象应用程序是所述非高可靠的应用程序时，所述确定单元确定所述多核处理器之中的没有被分配所述高可靠的应用程序的线程的核心；以及
通知单元，所述通知单元向所述确定单元所确定的核心通知所述对象线程的起动指示。
2.根据权利要求1所述的多核处理器系统，其特征在于，
在所述可靠度判断单元判断出所述对象应用程序是所述非高可靠的应用程序时，所述确定单元所确定所述多核处理器之中的没有被分配所述高可靠的应用程序的主线程的核心，
所述通知单元向所述确定单元所确定的核心通知所述对象线程的起动指示。
3.根据权利要求2所述的多核处理器系统，其特征在于，
在所述可靠度判断单元判断出所述对象应用程序是所述高可靠的应用程序的情况下，当所述对象线程是所述主线程时，所述通知单元向所述确定单元所确定的核心通知所述对象线程的起动指示，当所述对象线程不是所述主线程时，通知单元向所述多核处理器之中的任意的核心通知所述对象线程的起动指示。
4.根据权利要求1所述的多核处理器系统，其特征在于，
所述一个核心还包括：
检测单元，所述检测单元检测所述确定单元所确定的核心之中没有被分配任何线程的核心；
分配判断单元，在所述对象线程被分配给了所述检测单元所检测出的核心的情况下，所述分配判断单元判断是否向所述多核处理器的所有的核心都分配了所述非高可靠的应用程序的线程；以及
决定单元，在所述分配判断单元判断出向所述所有的核心都分配了所述非高可靠的应用程序的线程时，所述决定单元从所述确定的核心之中除所述检测出的核心之外的剩余的核心中决定分配所述对象线程的核心，在所述分配判断单元判断出并没有向所述所有的核心都分配所述非高可靠的应用程序的线程时，所述决定单元从所述确定的核心中决定分配所述对象线程的核心，
所述通知单元向所述决定单元所决定的核心通知所述对象线程的分配指示。
5.根据权利要求1所述的多核处理器系统，其特征在于，
所述一个核心还包括：
检测单元，所述检测单元检测出所述确定单元所确定的核心之中没有被分配任何线程分配的核心；
分配判断单元，在所述对象线程被分配给了所述检测单元所检测出的核心的情况下，所述分配判断单元判断是否向所述多核处理器的所有的核心都分配了所述高可靠的应用程序的线程；
决定单元，在所述分配判断单元判断出向所述所有的核心都分配了所述高可靠的应用程序的线程时，所述决定单元从所述确定的核心中除所述检测到的核心之外的剩余的核心中决定分配所述对象线程的核心，在所述分配判断单元判断出并没有向所述所有的核心都分配所述高可靠的应用程序的线程时，所述决定单元从所述确定的核心中决定分配所述对象线程的核心，
所述通知单元向所述决定单元所决定的核心通知所述对象线程的分配指示。
6.根据权利要求1至4中任一项所述的多核处理器系统，其特征在于，
在所述可靠度判断单元判断出所述对象应用程序是所述非高可靠的应用程序时，所述确定单元从在所述多核处理器中除所述一个核心之外的剩余的核心中确定没有分配所述高可靠的应用程序的线程的核心，
所述通知单元向所述确定单元所确定的核心通知所述对象线程的起动指示。
7.一种多核处理器系统，其特征在于，所述多核处理器系统包括多核处理器，当所述多核处理器内的一个核心通过调度器接收到线程的分配指示的通知时，所述多核处理器系统执行向多核处理器分配所述线程的分配处理，其中，
所述一个核心包括：
检测单元，所述检测单元检测出所述多核处理器之中停转的停转核心；
确定单元，所述确定单元确定因所述检测单元所检测到的停转核心的停转而崩溃的线程；以及
分配通知单元，所述分配通知单元将分配给所述多核处理器之中除了停转核心之外的剩余的核心的所述确定单元所确定的线程的分配指示通知给所述调度器。
8.根据权利要求7所述的多核处理器系统，其特征在于，
所述一个核心还包括：
重启通知单元，所述重启通知单元向所述检测单元所检测出的停转核心通知重启指示，
所述分配通知单元向通过所述重启通知单元所通知的重启指示而被重启的重启完毕的停转核心通知所述确定单元所确定的线程的起动指示，而不向所述调度器通知所述分配指示。
9.一种控制程序，其特征在于，所述控制程序使多核处理器内的一个核心执行以下工序，其中，所述多核处理器内的一个核心能够访问针对每个应用程序软件存储与动作相关的可靠度的存储装置，所述应用程序软件在以下称为“应用程序”，其中，所述工序包括：
提取工序，在所述提取工序中，从所述存储装置中提取起动对象线程的对象应用程序的可靠度；
可靠度判断工序，在所述可靠度判断工序中，基于在所述提取工序中提取的可靠度和指定阈值来判断所述对象应用程序是否是高可靠的应用程序；
确定工序，当在所述可靠度判断工序中判断为是所述高可靠的应用程序时，在确定工序中确定所述多核处理器之中的没有被分配非高可靠的应用程序的线程的核心，在判断为是所述非高可靠的应用程序时，在确定工序中确定所述多核处理器之中的没有被分配所述高可靠的应用程序的线程的核心；以及
通知工序，在所述通知工序中向在所述确定工序中所确定的核心通知所述对象线程的起动指示。
10.一种控制程序，其特征在于，所述控制程序使所述多核处理器内的一个核心执行以下工序，其中所述多核处理器内的一个核心在接收到线程的分配指示的通知时，通过调度器执行向多核处理器分配所述线程的分配处理，其中，所述工序包括：
检测工序，在所述检测工序中，检测出所述多核处理器之中停转的停转核心；
确定工序，在所述确定工序中，确定因在所述检测工序中所检测到的停转核心的停转而崩溃的线程；以及
分配通知工序，在所述分配通知工序中，将分配给所述多核处理器之中除了停转核心之外的剩余的核心的通过所述确定工序所确定的线程的分配指示通知给所述调度器。
11.一种控制方法，其特征在于，在所述控制方法中多核处理器内的一个核心执行以下工序，其中，所述多核处理器内的一个核心能够访问针对每个应用程序软件存储与动作相关的可靠度的存储装置，所述应用程序软件在以下称为“应用程序”，其中，所述工序包括：
提取工序，在所述提取工序中，从所述存储装置中提取起动对象线程的对象应用程序的可靠度；
可靠度判断工序，在所述可靠度判断工序中，基于在所述提取工序中提取的可靠度和指定阈值来判断所述对象应用程序是否是高可靠的应用程序；
确定工序，当在所述可靠度判断工序中判断为是所述高可靠的应用程序时，在确定工序中确定所述多核处理器之中的没有被分配非高可靠的应用程序的线程的核心，在判断为是所述非高可靠的应用程序时，在确定工序中确定所述多核处理器之中的没有被分配所述高可靠的应用程序的线程的核心；以及
通知工序，在所述通知工序中向在所述确定工序中所确定的核心通知所述对象线程的起动指示。
12.一种控制方法，其特征在于，在所述控制方法中所述多核处理器内的一个核心执行以下工序，其中，所述多核处理器内的一个核心在接收到线程的分配指示的通知时，通过调度器执行向多核处理器分配所述线程的分配处理，其中，所述工序包括：
检测工序，在所述检测工序中，检测出所述多核处理器之中停转的停转核心；
确定工序，在所述确定工序中，确定因在所述检测工序中检测到的停转核心的停转而崩溃的线程；以及
分配通知工序，在所述分配通知工序中，将向所述多核处理器之中除了停转核心之外的剩余的核心分配通过所述确定工序所确定的线程的分配指示通知给所述调度器。
CN2010800632389A 2010-02-23 2010-02-23 多核处理器系统、控制程序、以及控制方法 Pending CN102754079A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/052793 WO2011104824A1 (ja) 2010-02-23 2010-02-23 マルチコアプロセッサシステム、制御プログラム、および制御方法

Publications (1)

Publication Number Publication Date
CN102754079A true CN102754079A (zh) 2012-10-24

Family

ID=44506271

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2010800632389A Pending CN102754079A (zh) 2010-02-23 2010-02-23 多核处理器系统、控制程序、以及控制方法

Country Status (5)

Country Link
US (1) US20120304184A1 (zh)
EP (1) EP2541407A1 (zh)
JP (1) JPWO2011104824A1 (zh)
CN (1) CN102754079A (zh)
WO (1) WO2011104824A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106095654A (zh) * 2015-04-28 2016-11-09 瑞萨电子株式会社 性能验证装置、具有性能验证装置的系统以及方法
CN108334420A (zh) * 2017-01-19 2018-07-27 中国科学院声学研究所 一种基于多核网络处理器系统的数据恢复方法
CN110928601A (zh) * 2019-12-04 2020-03-27 锐捷网络股份有限公司 一种隔离cpu的方法、装置以及存储介质

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101295508B1 (ko) * 2011-09-09 2013-08-23 주식회사 팬택 스마트 단말기에서 어플리케이션을 실행하기 위한 제어 장치 및 그 방법
US9052911B2 (en) * 2012-08-14 2015-06-09 Oracle International Corporation Mechanism for consistent core hang detection in a a processor core
CN103631661B (zh) * 2013-11-27 2017-04-05 青岛海信电器股份有限公司 一种内存管理方法和装置
CN103870747B (zh) * 2014-03-31 2017-05-24 可牛网络技术（北京）有限公司 一种应用程序的监控及处理方法及装置
US10528443B2 (en) * 2015-01-30 2020-01-07 Samsung Electronics Co., Ltd. Validation of multiprocessor hardware component
CN104866460B (zh) * 2015-06-04 2017-10-10 电子科技大学 一种基于SoC的容错自适应可重构系统与方法
US11151002B2 (en) 2019-04-05 2021-10-19 International Business Machines Corporation Computing with unreliable processor cores
CN110990151A (zh) * 2019-11-24 2020-04-10 浪潮电子信息产业股份有限公司 一种基于异构计算平台的业务处理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070113231A1 (en) * 2005-11-11 2007-05-17 Hitachi, Ltd. Multi processor and task scheduling method
CN101006433A (zh) * 2004-08-25 2007-07-25 日本电气株式会社 信息通信装置和程序执行环境控制方法
WO2008062647A1 (en) * 2006-11-02 2008-05-29 Nec Corporation Multiprocessor system, system configuration method in multiprocessor system, and program thereof
CN101236515A (zh) * 2007-01-31 2008-08-06 迈普（四川）通信技术有限公司 多核系统单核异常的恢复方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2812045B2 (ja) * 1992-03-16 1998-10-15 株式会社日立製作所 高信頼型分散処理システム
JP2002202959A (ja) 2000-12-28 2002-07-19 Hitachi Ltd 動的な資源分配をする仮想計算機システム
CN101198934B (zh) 2005-06-17 2010-09-15 日本电气株式会社 信息处理设备和恢复方法
JP2008152594A (ja) 2006-12-19 2008-07-03 Hitachi Ltd マルチコアプロセッサ計算機の高信頼化方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101006433A (zh) * 2004-08-25 2007-07-25 日本电气株式会社 信息通信装置和程序执行环境控制方法
US20070113231A1 (en) * 2005-11-11 2007-05-17 Hitachi, Ltd. Multi processor and task scheduling method
WO2008062647A1 (en) * 2006-11-02 2008-05-29 Nec Corporation Multiprocessor system, system configuration method in multiprocessor system, and program thereof
CN101236515A (zh) * 2007-01-31 2008-08-06 迈普（四川）通信技术有限公司 多核系统单核异常的恢复方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106095654A (zh) * 2015-04-28 2016-11-09 瑞萨电子株式会社 性能验证装置、具有性能验证装置的系统以及方法
CN106095654B (zh) * 2015-04-28 2021-04-02 瑞萨电子株式会社 性能验证装置、性能验证系统以及性能验证方法
CN108334420A (zh) * 2017-01-19 2018-07-27 中国科学院声学研究所 一种基于多核网络处理器系统的数据恢复方法
CN108334420B (zh) * 2017-01-19 2021-06-08 中国科学院声学研究所 一种基于多核网络处理器系统的数据恢复方法
CN110928601A (zh) * 2019-12-04 2020-03-27 锐捷网络股份有限公司 一种隔离cpu的方法、装置以及存储介质
CN110928601B (zh) * 2019-12-04 2022-05-20 锐捷网络股份有限公司 一种隔离cpu的方法、装置以及存储介质

Also Published As

Publication number Publication date
JPWO2011104824A1 (ja) 2013-06-17
EP2541407A1 (en) 2013-01-02
WO2011104824A1 (ja) 2011-09-01
US20120304184A1 (en) 2012-11-29

Similar Documents

Publication Publication Date Title
CN102754079A (zh) 多核处理器系统、控制程序、以及控制方法
US7774636B2 (en) Method and system for kernel panic recovery
US8402462B2 (en) Detection and management of dynamic migration of virtual environments
US8429669B2 (en) Virtual machine switching control by prefetching information out of and updating a set of processor control information based on a bitmap having update status
CN101025701A (zh) 存储器转储方法、存储器转储程序以及计算机系统
JP5382450B2 (ja) アクセス制御装置、その方法及び情報記録媒体
US20080005609A1 (en) Method and apparatus for OS independent platform recovery
EP2765525B1 (en) Apparatus, non-transitory computer readable information recording medium and information recording method
CN103309751A (zh) 提供文件系统功能的终端的设备和方法
CN109375921A (zh) 页面文件快速编译方法、装置及存储设备、计算机设备
US9009537B2 (en) Diagnostic data capture in a computing environment
CN115480931A (zh) 一种核间通信处理方法、装置及计算机系统
JP2690435B2 (ja) 処理をプロセッサにディスパッチするためのマイクロプログラム手段を有するマルチプロセッサシステム
EP2876557B1 (en) Detecting a read access to unallocated or uninitialized memory
CN106354560B (zh) 一种系统的维护进程运行方法及装置
CN111831432A (zh) Io请求的调度方法、装置、存储介质及电子设备
CN111831409B (zh) 线程调度方法、装置、存储介质及电子设备
WO2009147738A1 (ja) 情報処理装置及びその制御方法並びにモニタプログラム
JP4825120B2 (ja) サービス管理システム、サービス管理装置およびサービス管理方法
CN109086179B (zh) 一种程序异常情况下的处理方法和装置
González Java 9 concurrency cookbook
CN108363618A (zh) 一种进程处理的方法和装置
US20090241111A1 (en) Recording medium having instruction log acquiring program recorded therein and virtual computer system
CN115840617A (zh) 一种调试方法、系统及相关装置
Radovici et al. The Tock System Architecture

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C05 Deemed withdrawal (patent law before 1993)
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20121024