等待日志调用返回的线程转移的制作方法

文档序号:15575352发布日期:2018-09-29 05:24阅读:173来源:国知局

计算机系统和相关技术影响社会的许多方面。实际上,计算机系统处理信息的能力改变了我们生活和工作的方式。现在,计算机系统通常执行在计算机系统出现之前由人工执行的大量任务(例如,文字处理、调度、计费等)。最近,计算机系统已经被耦合到其他计算机系统以及耦合到其他电子设备,以形成有线和无线计算机网络,计算机系统和其他电子设备可通过该网络传输电子数据。

计算系统现在能够运行数百个程序。例如,进程就是程序的实例。然而,计算系统上的处理能力仍然是固定的。为了允许有序地处理在计算系统上运行的各种程序,调度器为每个程序分配时间。然而,调度器看到的最小指令集通常称为“线程”。线程通常在较大的处理单元的背景下实现,例如进程、组件或程序。

当处理单元生成将由线程进行记录的事件时,该线程调用记录组件。传统上,对事件进行记录在相对计算方面可能需要相当长的时间-可能在毫秒和数百微秒的范围内。在此期间,线程通常要么处于空闲状态,要么处于睡眠模式,以便消耗更少的计算资源。无论哪种方式,调用记录组件的线程在返回调用之前,通常无法继续针对处理单元的执行。

本公开要求保护的技术方案不限于解决任何缺点或仅在诸如上述那些环境中操作的实施例。而是,提供该背景仅用于说明可以实践本公开描述的一些实施例的一个示例性技术领域。



技术实现要素:

本公开描述的至少一些实施例涉及线程的有效使用,其对记录组件发出调用以对事件进行记录。在等待确定事件已被记录时(例如,通过同步实施例中的调用返回,或通过异步实施例中的轮询),这些线程在处理单元的不生成事件的一部分的其他任务上工作,而不是使线程处于空闲状态。这可以在没有线程的上下文切换的情况下发生,尤其是当要执行的任务是无状态或无上下文时。即使事件日志调用的调用时间和返回时间之间的等待时间很短,使用线程也是有效的。

在有效的线程转移进程中,线程调用记录组件,以对事件进行记录。这会阻止线程继续为事件所属的处理单元工作,直到可以确定事件已被记录为止。在发出调用之后,线程自动执行一个或多个任务,这些任务不属于事件所属的处理单元的一部分。这在等待确定事件已被记录的同时有效地使用线程。在确定已对事件进行记录之后,线程继续为事件发生的处理单元工作。对于每个线程和对于多线程,这可以重复多次,从而提供执行后台任务的能力的实质性改进,特别是对于那些可暂停和可恢复的和/或花费与记录的调用与完成之间的等待时间一样多或一样少的处理时间的任务。

提供本发明内容是为了以简化的形式介绍一些概念,这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征,也不旨在用于帮助确定所要求保护的主题的范围。

附图说明

为了描述可以获得本发明的上述和其他优点和特征的方式,将通过参考附图所示的具体实施例来呈现上面简要描述的本发明的更具体的描述。应当理解,这些附图仅描绘了本发明的典型实施例,因此不应认为是对其范围的限制,本发明将借助于使用附图通过附加特征和细节进行描述和解释,附图中:

图1示出了可以采用本公开描述的原理的示例计算系统;

图2示出了根据本公开描述的原理的系统,其中事件提供程序通过具有使事件日志调用进入到记录组件的线程而将事件写入记录组件,并且其中转移任务组件使线程工作以执行转移任务同时等待确定事件已经被记录(例如通过日志调用返回);

图3象征性地示出了操作两个线程的处理单元,随着时间的推移在线程之间切换;

图4示出了用于记录计算系统的事件的方法的流程图,在该方法中允许线程被转移同时等待确定事件已经被记录;

图5示出了根据本公开描述的原理的用于选择转移任务的方法的流程图;并且

图6示出了用于从根据预期处理时间组织的转移任务组中选择转移任务的方法的流程图。

具体实施方式

本公开描述的至少一些实施例涉及线程的有效使用,其对记录组件发出调用以对事件进行记录。在等待确定事件已被记录时(例如,通过同步实施例中的调用返回,或通过异步实施例中的轮询),这些线程在处理单元的不生成事件的一部分的其他任务上工作,而不是使线程处于空闲状态。这可以在没有线程的上下文切换的情况下发生,尤其是当要执行的任务是无状态或无上下文时。即使事件日志调用的调用时间和返回时间之间的等待时间很短,使用线程也是有效的。

在有效的线程转移进程中,线程调用记录组件来对事件进行记录。这会阻止线程继续为事件所属的处理单元工作,直到可以确定事件已被记录为止。在发出调用之后,线程自动执行一个或多个任务,这些任务不属于事件所属的处理单元的一部分。这在等待确定事件已被记录的同时有效地使用线程。在确定已对事件进行记录之后,线程继续为事件发生的处理单元工作。对于每个线程和对于多线程,这可以重复多次,从而提供执行后台任务的能力的实质性改进,特别是对于那些可暂停和可恢复的和/或花费与记录的调用与完成之间的等待时间一样多或一样少的处理时间的任务。

将参照图1描述计算系统的一些介绍性讨论。然后,将参照图2至图6描述在等待完成记录的同时执行转移任务的线程的有效转移。

计算系统现在越来越多地采用各种形式。例如,计算系统可以是手持设备、器具、膝上型计算机、台式计算机、大型机、分布式计算系统、数据中心、或者甚至通常不被认为是计算系统的设备,例如可穿戴设备(例如眼镜)。在本说明书和权利要求书中,术语“计算系统”被广义地定义为包括任何这样的设备或系统(或其组合),该设备或系统包括至少一个物理和有形处理器,以及能够在其上具有可由处理器执行的计算机可执行指令的物理和有形存储器。存储器可以采用任何形式,并且可以根据计算系统的性质和形式而不同。计算系统可以分布在网络环境上,并且可以包括多个组成计算系统。

如图1所示,在其最基本配置中,计算系统100通常包括至少一个硬件处理单元102和存储器104。存储器104可以是物理系统存储器,其可以是易失性的、非易失性的、或两者的一些组合。术语“存储器”在本公开中还可以用于指代非易失性大容量存储器,例如物理存储介质。如果计算系统是分布式的,则处理、存储器和/或存储能力也可以是分布式的。

计算系统100上还具有通常被称为“可执行组件”的多个结构。例如,计算系统100的存储器104被示出为包括可执行组件106。术语“可执行组件”是本领域普通技术人员在计算领域中容易理解的结构名称,该结构可以是软件、硬件或其组合。例如,当以软件实现时,本领域普通技术人员应当理解,可执行组件的结构可以包括可以在计算系统上执行的软件对象、例程、方法,而无论这样的可执行组件是否存在于计算系统的堆中或者可执行组件是否存在于计算机可读存储介质上。

在这种情况下,本领域普通技术人员应当认识到,可执行组件的结构存在于计算机可读介质上,使得当由计算系统的一个或多个处理器(例如由处理器线程)解释时,致使计算系统执行功能。这种结构可以由处理器直接计算机读取(如可执行组件是二进制的情况一样)。可替换地,该结构可以被构造成可解释和/或编译(无论是在单个阶段还是在多个阶段中),以便生成可由处理器直接解释的这种二进制。当使用术语“可执行组件”时,对可执行组件的示例结构的这种理解完全在计算领域的普通技术人员的理解之内。

本领域普通技术人员也很好理解术语“可执行组件”,其包括专门或几乎专门在位于诸如现场可编程门阵列(fpga)、专用集成电路(asic)或任何其他专用电路内的硬件中实现的结构。因此,术语“可执行组件”是计算领域的普通技术人员很好理解的结构的术语,无论是以软件、硬件还是组合实现。在本说明书中,还可以使用术语“组件”、“服务”、“引擎”、“模块”、“虚拟机”等。如在本说明书中和该情况下所使用的,这些术语(无论是否以修饰条款表达)也旨在与术语“可执行组件”同义,因此也具有计算领域的普通技术人员理解的结构。

在以下描述中,参考由一个或多个计算系统执行的动作来描述实施例。如果这些动作是以软件实现的,则(执行该动作的相关计算系统的)一个或多个处理器响应于已经执行构成可执行组件的计算机可执行指令来指导计算系统的操作。例如,这样的计算机可执行指令可以体现在形成计算机程序产品的一个或多个计算机可读介质上。这种操作的一个实例涉及数据的操纵。

计算机可执行指令(和所操纵的数据)可以存储在计算系统100的存储器104中。计算系统100还可以包含允许计算系统100在例如网络110上与其他计算系统通信的通信信道108。

尽管并非所有计算系统都需要用户界面,然而在一些实施例中,计算系统100包括用于与用户交互的用户界面112。用户界面112可以包括输出机构112a以及输入机构112b。这里描述的原理不限于精确的输出机构112a或输入机构112b,因为这根据设备的性质而不同。然而,输出机构112a可以包括例如扬声器、显示器、触觉输出、全息图等。输入机构112b的实例可以包括例如麦克风、触摸屏、全息图、相机、键盘、其他指针输入的鼠标、任何类型的传感器等。

本公开描述的实施例可以包括或利用专用或通用计算系统,该计算系统包括计算机硬件,诸如例如一个或多个处理器和系统存储器,如下面更详细地讨论的。本公开描述的实施例还包括用于携带或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这种计算机可读介质可以是可由通用或专用计算系统访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。携带计算机可执行指令的计算机可读介质是传输介质。因此,作为示例而非限制,本发明的实施例可以包括至少两种截然不同的计算机可读介质:存储介质和传输介质。

计算机可读存储介质包括ram、rom、eeprom、cd-rom或其他光盘存储器、磁盘存储器或其他磁存储设备,或者可用于存储所需程序代码的任何其他物理和有形存储介质。“计算机可执行指令”指的是计算机可执行指令或数据结构的形式,并且可以由通用或专用计算系统访问。

“网络”被定义为能够在计算系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当通过网络或另一通信连接(硬连线、无线或硬连线或无线的组合)向计算系统传送或提供信息时,计算系统将连接正确地视为传输介质。传输介质可以包括网络和/或数据链路,其可以用于以计算机可执行指令或数据结构的形式携带期望的程序代码方式,并且可以由通用或专用计算系统访问。上述的组合也应包括在计算机可读介质的范围内。

此外,在到达各种计算系统组件时,计算机可执行指令或数据结构形式的程序代码方式可以自动地从传输介质传输到存储介质(或反之亦然)。例如,通过网络或数据链路接收的计算机可执行指令或数据结构可以在网络接口模块(例如“nic”)内的ram中缓冲,然后最终传送到计算系统ram和/或计算系统中的更不易性存储介质。因此,应当理解,存储介质可以包括在也(或甚至主要)利用传输介质的计算系统组件中。

计算机可执行指令包括例如指令和数据,当在处理器处执行时,所述指令和数据致使通用计算系统、专用计算系统或专用处理设备执行特定功能或功能组。可替换地或另外地,计算机可执行指令可以将计算系统配置为执行特定功能或功能组。计算机可执行指令可以是例如二进制或甚至在处理器直接执行之前经历一些转换(例如编译)的指令,诸如中间格式指令(诸如汇编语言)或者甚至源代码。

尽管使用结构特征和/或方法动作专用的语言描述了本主题,然而应当理解,所附权利要求书中定义的主题不必限于上述所描述的特征或动作。而是,所描述的特征和动作被公开为实现权利要求的示例形式。

本领域技术人员应当理解,本发明可以在具有多种类型的计算系统配置的网络计算环境中实践,所述计算系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持设备、多处理器系统、基于微处理器或可编程的消费电子产品、网络pc、小型计算机、大型计算机、移动电话、pda、寻呼机、路由器、交换机、数据中心、可穿戴设备(例如眼镜)等。本发明还可以在分布式系统环境中实施,其中通过网络链接(通过硬连线数据链路、无线数据链路或通过硬连线和无线数据链路的组合)的本地和远程计算系统都执行任务。在分布式系统环境中,程序模块可以位于本地和远程存储器存储设备中。

本领域技术人员还应当理解,本发明可以在云计算环境中实施。云计算环境可以是分布式,但这不是必需的。当是分布式时,云计算环境可以在组织内进行国际分布和/或具有在多个组织上所拥有的组件。在本说明书和以下权利要求中,“云计算”被定义为用于实现对可配置计算资源(例如网络、服务器、存储、应用和服务)的共享池的按需网络访问的模型。“云计算”的定义不限于在适当部署时可从这种模型获得的任何其他众多优点。

图2示出了根据本公开描述的原理的系统200。系统200包括记录组件201,其可以如上面针对图1的可执行组件106所描述的那样构造。此外,系统200可以如上面针对图1的计算系统100所描述的那样构造。记录组件201导致如箭头203表示的待写入日志202的事件。日志202可以表示用于对事件进行记录的任何介质。仅作为示例,日志202可以是本地或远程硬盘驱动器、固态盘或其组合,或者包括其的磁盘阵列。可替换地或另外地,日志202可以是存储器(包括系统存储器)并且可以是非易失性的或易失性的。可替换地或另外地,日志202还可以存在于多个目标上,例如主计算系统和辅助计算系统上。可替换地或另外地,日志202可以位于单个机器上,或者可以是分布式的,例如在云计算环境中。

系统200包括一组事件提供程序210,其向记录组件201提供事件以用于记录。具体地,事件提供程序具有使调用(下文中也称为“事件日志调用”)进入记录组件201的线程,以便对事件进行记录。例如,在一个实例中,事件提供程序210a首先提供如箭头211a所示的事件(下文称为“事件a”)。然后,事件提供程序210b提供如箭头211b所示的事件(下文称为“事件b”)。事件提供程序210被示出为包括两个事件提供程序210a和210b。然而,这里描述的原理与有多少事件提供程序将事件提供到日志中无关。因此,提供省略号210c以表示提供待进行记录的事件的事件提供程序的数量的灵活性。事件提供程序可以是任何软件或硬件组件或系统,无论是本地驻留在系统200上还是位于远程位置。

图3示出了操作一个或多个线程的处理单元300。处理单元是其中关联或包含线程的任何处理单元,并且当从一个线程切换到另一个线程时改变上下文。某些操作系统中的示例是进程、程序或组件。例如,处理单元300被示出为包括两个线程,线程301和线程302。在时间t1,处理单元300单元从操作线程301切换到操作线程302。在时间t2,处理单元300从操作线程302切换到操作线程301。每次操作线程改变时,存在占用一些计算资源的上下文切换。

在任何情况下,当线程对记录组件进行i/o调用(例如事件日志调用)时,线程通常不能继续在线程的相关处理单元内工作,直到确定i/o已经完成(例如,通过同步实施例中的调用返回,或者通过异步实施例中的轮询)为止。否则,存在处理单元所使用的资源状态(例如共享存储器)不一致的风险。如果在工作完成之前需要很长时间,则可能将线程置于睡眠模式以便保留计算资源。例如,调用记录组件201以请求对事件a进行记录的(事件提供程序210a的)线程将不在事件提供程序210a的处理单元的上下文中操作,直到由调用引起的工作完成为止。此外,调用记录组件201以请求对事件进行记录b的线程(事件提供器210b)将不再在其事件提供器210b的处理单元的上下文中操作,直到由调用引起的工作完成为止。

返回到图2,系统200还包括线程转移组件212,其导致线程在线程调用记录组件对事件进行记录之后自动执行不属于处理单元的任务(下文中也称为“转移任务”),同时线程正在等待调用返回。在检测到调用已经返回之后,系统200允许线程继续为生成事件的处理单元工作。因此,线程转移组件212将空闲线程用于转移任务,同时它们等待指令返回其正常工作,从而有效地使用线程和计算机资源。

系统200还包括转移任务库213,转移任务库包括可以由等待调用工作完成的线程完成的多个任务。可以将转移任务组织成共同处理时间范围的组。例如,预期在特定时间范围内可处理的转移任务被分组为一组。尽管可能只有一个组,然而在图2中,显示了三个组220,包括组221、222和223。椭圆224表示组220的数量的灵活性。此外,在每个组内,可以存在任意数量的转移任务,除了组221中的一个转移任务230之外,这些转移任务未在图2中示出。在某些情况下,组甚至可能是空的。然而,每个组中可以有少至一个到多个转移任务,每个组按预期的处理时间范围组织。

在一些实施例中,转移任务可以是无上下文或无状态的转移任务。这允许线程在转移任务上工作,而无论线程目前具有什么状态,因为状态都不会影响转移任务的性能或受其影响。因此,当线程恢复处理单元的正常工作时,就好像线程一直在等待,而正常处理所期望的状态没有变化。此外,可以在不切换线程状态的情况下执行转移任务,从而降低执行转移的成本。无上下文且通常可以在预定时间范围内处理的任务的一个示例是垃圾收集任务。

在一个实施例中,任务也可以是可使用的和可恢复的。因此,如果事件日志调用在线程仍在处理转移任务时返回,则线程可以暂停对转移任务的工作,并返回到处理单元的正常工作。当线程或另一个线程再次进行事件日志调用时,可以通过进行较新事件日志调用的线程恢复相同的转移任务。为了促进这种暂停和恢复,转移任务本身可以保持足够的状态以使得转移任务可以暂停并且稍后恢复。

图4示出了用于对计算系统的事件进行记录同时允许线程在等待事件日志调用工作完成时被转移的方法400的流程图。方法400可以在图2的系统200的上下文中执行。因此,现在将频繁地参考图2的系统200来描述方法400。可以在每次线程调用记录组件200执行事件写入时执行方法400。例如,参考图2,方法400将在写入事件a时以及也在写入事件b时执行。

方法400包括调用记录组件以对事件进行记录的线程(动作401)。例如,假设图3的处理单元300正在处理事件写入器210a,则线程301可以调用记录组件201(参见图2)来写入事件a。从那时起直到调用工作完成(例如调用返回),线程301不能继续在处理单元300中工作。换言之,线程被阻止继续在事件所属的处理单元300上工作,直到完成调用工作。事件日志调用的存在可以触发线程转移组件211进入操作。

还在等待事件日志调用返回的同时为线程选择一个或多个转移任务的组(动作402)。这里描述的原理不限于何时进行该选择,或者什么组件进行选择。可以在事件日志调用之前很好地进行选择,然而可以响应于事件日志调用工作完成或其间的任何时间进行选择。因此,为了在最广泛的上下文中表示事件日志调用和转移任务选择之间的这种时间独立性,在图4中并行示出了动作401和402。图5和图6示出了用于选择转移任务的各种可能机制。然而,在描述这些机制之前,将完成图4的描述。

在线程调用记录组件以对事件进行记录之后,线程自动执行所选择的转移任务(动作403)。例如,在图2中,线程转移组件212可以选择转移任务230以供线程执行(例如,对于执行由事件a表示的事件日志调用的线程)。如果选择了多于一个转移任务,则可能在执行转移任务之间,线程转移组件可以验证事件日志调用是否已经返回(在同步实施例中),或者轮询记录组件(在异步实施例中)以确定记录是否已完成。因此,线程可以执行所选择的转移任务230。此后,确定事件已被记录(动作404),导致线程继续在事件所属的处理单元上工作-换言之,恢复处理单元的正常工作。同样,确定事件已被记录可以是同步的(如调用返回时)或异步的(在这种情况下,转移组件通过轮询记录组件来获知完成)。

在一个实施例中,转移任务的选择被设计为允许转移任务大概在事件日志调用返回之时完成或在之前完成。然而,在一些实施例中,为了有效地使用资源,允许完成正在进行的转移任务(在确定完成事件日志时)。图5和图6示出了用于在该上下文中选择转移任务的方法500和600的流程图。根据图5,选择处理估计事件日志调用与事件日志调用返回的时间之间的预期等待时间(动作501)。等待时间量根据系统而变。然而,根据本公开描述的原理,该等待时间可能非常短-可能是50微秒或更短,或者可能是25微秒或更短。

然后,从任务或任务组中选择转移任务(动作502),该任务或任务组具有与调用时间与调用返回时间之间的估计预期等待时间大致相同或更小的可预测处理时间范围。例如,如果等待时间预期为30微秒,则可以选择具有允许在大约30微秒或更短时间内完成的预期处理时间的转移任务的组。

图6示出了用于选择转移任务的方法600,该转移任务具有可预测时间范围并且表示在其作为通过预期处理时间范围分组的任务的上下文中的动作502的示例。例如,在图2中,转移任务组220被分组为组221、222和223,每个组在其中具有不同的预期处理时间范围的转移任务。根据方法600,该选择首先选择任务的组(动作601),使得从所选择的组中选择的任务的共同的预期处理时间范围可以等于或小于调用时间与调用返回时间之间的估计预期等待时间。例如,在图2中,可以选择组221。然后,该选择从所选择的组内选择一个或多个转移任务(动作602)。例如,该选择可以从组221中选择任务230。

可替换地或另外地,转移任务可以是可暂停的和可恢复的任务。在这种情况下,也许可以选择转移任务而更少考虑转移任务是否可以在调用与其返回之间的预期等待时间段内处理。毕竟,如果无法及时完成转移任务以紧接在事件日志调用返回后继续,则可以暂停转移任务。例如,在线程继续在事件所属的处理单元上工作之前(动作405),线程可以暂停转移任务以供稍后由相同线程或不同线程恢复。在暂停之前,线程可以等待调用返回(动作404)。可替换地或另外地,转移任务可以执行预定时间段或/或直到满足另一条件,而不考虑调用是否返回。在这种情况下,当选择转移任务时,线程还将暂停可以从中选择该线程的转移任务。如果选择了暂停的任务(在动作402中),则恢复暂停的任务。

因此,这里描述的原理提供了用于在线程进行事件日志调用的时间与确定完成记录的时间之间的至少一些时间段内有效地使用线程的机制。通常,线程可以简单地处于空闲状态,或者处于睡眠模式。然而,使用这里描述的原理,线程被有效地用于转移任务。这种转移任务可以是除了正常处理之外可以执行的无状态任务。此类后台任务的示例包括垃圾收集。由于对于任何给定的线程,该进程可以重复多次,并且由于可以对多个线程执行该进程,因此这可以显著提高计算系统的效率以及其完成后台任务的能力。

在不脱离本发明的精神或基本特征的情况下,本发明可以以其他特定形式实施。所描述的实施例在所有方面都应被视为仅是说明性的而非限制性的。因此,本发明的范围由所附权利要求而不是前面的描述表示。在权利要求的含义和等同范围内的所有变化都包含在其范围内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1