[发明专利]一种基于中断重入机制的协程处理及管理方法

说明书

本发明公开了一种基于中断重入机制的协程处理及管理方法，处理方法中，所述协程包括主协程和子协程，中断重入步骤包括：S1：所述主协程抛出中断请求，所述主协程的底层框架响应所述中断请求并异步发送任务请求；S2：切换至外部系统处理逻辑，所述主协程释放线程资源；S3：所述任务请求应答通过回调接口执行重入所述子协程，并恢复至中断时上下文状态；S4：所述子协程继续处理后续逻辑，直到执行结束，释放线程资源；或者子协程作为新的主协程抛出中断请求，重复上述步骤S1至S4；管理方法中，上述协程组合为应用，所述应用程序入口OnProcess()内包括处理方法中的CallBatch()接口。本发明大幅降低了有大量并行分支的调度程序开发、维护的复杂度和工作量。

技术领域

本发明属于计算机技术领域，尤其涉及一种基于中断重入机制的协程处理及管理方法。

背景技术

业务应用开发中经常需要开发一些调度程序，这些程序需要同时推进很多分支流程，并且很多分支流程会由于与外部的协作而需要很长的执行时间，例如图1所示的调度过程(其中，B、C、D都表示提交一个批处理任务并等待该任务的完成结果)。采用常见的编程语言开发上述调度程序，通常都以同步阻塞方式实现与外部的协作，因此只能采用多线程实现多分支并行推进，其工作机制如图2所示。很明显，这样的程序存在的问题是，一旦需要大规模并行推进(例如并行分支超过1000个)，并且很多分支都存在长时间同步阻塞的场景，则运行时线程资源消耗巨大。

为解决线程资源消耗过大问题，业界常见做法是采用异步回调方式编程，其工作机制如图3所示。很明显，线程资源的消耗被降到最低，但这样的程序存在的问题是编程模型复杂，不符合人的思维习惯，代码的可维护性差，甚至无法支持组件化开发，不能把Process方法封装成一个在E动作完成时返回完成结果的方法。

在较新的编程语言Go、C#中，开发人员可以基于协程编程模型来开发这些调度程序，其工作机制如图4所示。这种工作机制在线程模型层面和异步回调编程的程序几乎一样：所有等待动作都会导致协程挂起，全部协程挂起后则主线程终止。收到应答后，会在新线程中继续推进被唤醒的协程。显然，这样的程序不仅能将线程资源的消耗降到最低，且编程模型符合人的思维习惯，代码可维护性好，并能够支持组件化开发。遗憾的是，支持这种协程编程模型的语言较少，目前行业运用最广泛的Java、C++等语言均不支持；而即使语言本身支持这种协程编程模型，大多数语言一般也不支持程序自动具备一些高可用特性，如同一调度程序可换机运行、系统宕机恢复后程序能够继续执行。

因此，目前急需一种基于中断重入机制的协程处理及管理方法，以弥补上述方法中的缺陷。

发明内容

针对上述问题，本发明提供了一种基于中断重入机制的协程处理及管理方法，采用可维护性更好的同步阻塞编程模型开发有大量并行分支的调度程序，大幅降低了此类程序开发、维护的复杂度和工作量，且能够支持程序进行组件化开发，不受编程语言的约束。

为了实现上述目的，本发明采用的技术方案为：

一种基于中断重入机制的协程处理方法，所述协程包括主协程和子协程，中断重入步骤包括：

S1：所述主协程抛出中断请求，所述主协程的底层框架响应所述中断请求并异步发送任务请求；

S2：切换至外部系统处理逻辑，所述主协程释放线程资源；

S3：所述任务请求应答通过回调接口执行重入所述子协程，并恢复至中断时上下文状态；

S4：所述子协程继续处理后续逻辑，直到执行结束，释放线程资源；或者子协程作为新的主协程抛出中断请求，重复上述步骤S1至S4。

优选地，步骤S1还包括，所述主协程首次抛出中断请求前，建立中断记忆对象并登记到记忆存储器中，所述记忆对象用于储存不可重复动作的执行结果，所述记忆存储器用于储存中断处上下文；