CN106371809B - 线程处理器及线程处理方法 - Google Patents

线程处理器及线程处理方法 Download PDF

Info

Publication number
CN106371809B
CN106371809B CN201610797409.XA CN201610797409A CN106371809B CN 106371809 B CN106371809 B CN 106371809B CN 201610797409 A CN201610797409 A CN 201610797409A CN 106371809 B CN106371809 B CN 106371809B
Authority
CN
China
Prior art keywords
thread
windows
function
linux
processing
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.)
Active
Application number
CN201610797409.XA
Other languages
English (en)
Other versions
CN106371809A (zh
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.)
Beijing Qihoo Technology Co Ltd
Original Assignee
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co 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 Beijing Qihoo Technology Co Ltd, Qizhi Software Beijing Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Priority to CN201610797409.XA priority Critical patent/CN106371809B/zh
Priority to US15/741,133 priority patent/US20190087221A1/en
Priority to PCT/CN2016/104062 priority patent/WO2018040271A1/zh
Publication of CN106371809A publication Critical patent/CN106371809A/zh
Application granted granted Critical
Publication of CN106371809B publication Critical patent/CN106371809B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/524—Deadlock detection or avoidance
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • 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/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • 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/5055—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 software capabilities, i.e. software resources associated or available to the machine
    • 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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Landscapes

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

Abstract

本发明公开了一种线程处理器及线程处理方法，其中，线程处理器基于Windows系统实现对Linux线程的处理，线程处理器包括：线程功能转换模块，适于解析Linux线程的处理功能，将Linux线程的处理功能转换为对应的Windows线程的处理功能；线程数据结构转换模块，适于解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构；线程阻塞管理模块，适于循环检测通过功能转换和数据结构转换运行于Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。根据本发明提供的技术方案，实现了在Windows系统上处理Linux线程，且Linux线程在Windows系统上运行的效果如同在Linux系统上运行的效果，为Android应用程序在Windows系统上的运行提供了极大的便利。

Description

线程处理器及线程处理方法
技术领域
本发明涉及计算机软件技术领域，具体涉及一种线程处理器及线程处理方法。
背景技术
随着Android操作系统的移动终端的普及，应用市场随即出现越来越多应用于Android操作系统的移动终端的Android应用程序，这些Android应用程序极大的满足了用户生活、娱乐、购物等需求。但移动终端由于其本身方便携带等移动特性的限制，使得移动终端存在屏幕较小、处理器易发热、电池续航能力不足、网络信号不稳定等问题，造成用户的视觉体验不高，在使用时易产生用户在操作过程中被中断或停滞等状况。对此，用户可以通过使用Windows系统的PC机运行Android应用程序来解决。
在Windows系统的PC机侧安装Android虚拟机，在该Android虚拟机中虚拟运行Android操作系统，可以实现在Windows系统的PC机上运行 Android应用程序，使用户能够在较大的显示屏中感受较好的视觉体验及运行速度的提升。但这种方式由于Android虚拟机中本身运行时需要耗费PC 机侧大量的硬盘空间和内存，一定程度上也对PC机运行Android应用程序的速度造成影响。
在Android应用程序中包括了很多Linux系统线程处理，在Windows系统运行Android应用程序时，需要同时也实现对Linux线程的处理。由于 Windows线程与Linux线程的运行处理机制不同，因此需要一种可以在 Windows系统实现对Linux线程的处理的处理器或处理方法，但现有技术还没有在Windows系统中实现对Linux线程的处理的处理器或处理方法。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种线程处理器及线程处理方法。
根据本发明的一个方面，提供了一种线程处理器，线程处理器基于 Windows系统实现对Linux线程的处理，线程处理器包括：
线程功能转换模块，适于解析Linux线程的处理功能，将Linux线程的处理功能转换为对应的Windows线程的处理功能；
线程数据结构转换模块，适于解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构；
线程阻塞管理模块，适于循环检测通过功能转换和数据结构转换运行于 Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。
根据本发明的另一方面，提供了一种线程处理方法，方法基于Windows 系统实现对Linux线程的处理，方法包括：
线程功能转换步骤，解析Linux线程的处理功能，将Linux线程的处理功能转换为对应的Windows线程的处理功能；
线程数据结构转换步骤，解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构；
线程阻塞管理步骤，循环检测通过功能转换和数据结构转换运行于 Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。
根据本发明提供的线程处理器及线程处理方法，执行线程功能转换模块解析Linux线程的处理功能，将Linux线程的处理功能转换为对应的Windows 线程的处理功能。执行线程数据结构转换模块解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构。执行线程阻塞管理模块循环检测通过功能转换和数据结构转换运行于 Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。实现了在Windows系统上处理Linux线程，且Linux线程在Windows系统上运行的效果如同在Linux系统上运行的效果，为Android应用程序在Windows 系统上的运行提供了极大的便利。与在Windows系统安装Android虚拟机相比，极大的减少了系统资源的占用，无需用户执行复杂的安装操作，提供给用户更好的使用体验。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了根据本发明一个实施例的线程处理器的功能框图；
图2示出了根据本发明另一个实施例的线程处理器的功能框图；
图3示出了根据本发明另一个实施例的线程处理器的功能框图；
图4示出了根据本发明一个实施例的线程处理方法的流程图；
图5示出了根据本发明另一个实施例的线程处理方法的流程图
图6示出了根据本发明另一个实施例的线程处理方法的流程图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一个实施例的线程处理器的功能框图。线程处理器基于Windows系统实现对Linux线程的处理，如图1所示，线程处理器具体包括如下模块：
线程功能转换模块110，适于解析Linux线程的处理功能，将Linux线程的处理功能转换为对应的Windows线程的处理功能。
Linux线程中调用的为适用于Linux系统的各种函数，这些函数无法在 Windows系统上直接执行，需要线程功能转换模块110对其实现的功能进行转换。线程功能转换模块110转换时使用在Windows系统上适用的函数进行相应的功能替换。
线程功能转换模块110在解析Linux线程的处理功能后，需要找到与实现Linux线程的处理功能的一个或多个函数相对应的Windows线程使用的函数，并根据Linux线程中函数的调用顺序或功能处理的顺序，依次调用对应的Windows线程使用的函数。若实现Linux线程的处理功能的一个或多个函数在Windows系统中没有其对应的函数，线程功能转换模块110还需要将该一个或多个函数的功能在Windows系统上完成对应的实现，并将该实现函数与其他对应的Windows线程使用的函数按照Linux线程中函数的调用顺序或功能处理的顺序进行调用。如某个Linux线程A，其中，Linux线程A包括调用函数A1、函数A2、函数A3。线程功能转换模块110调用对应的Windows 系统中的函数B1、函数B2、函数B3。其中，函数B1实现了函数A1中的功能，函数B2实现了函数A2中的功能，函数B3实现了函数A3中的功能。或函数B2实现了函数A2和函数A3中的功能，线程功能转换模块110仅调用对应的Windows系统中的函数B1和函数B2。或者，Windows系统中没有与函数A1实现的功能对应的方法，线程功能转换模块110需要将函数A1实现的功能进行实现，在实现函数A1对应的功能后，还需要进一步调用 Windows系统中实现了函数A2和函数A3中功能所对应的方法。
进一步，在线程功能转换模块110调用对应的Windows线程的函数时，需要注意函数中调用的参数，传递正确的参数以便Windows线程的函数进行调用。如Windows线程中函数调用的参数与Linux线程的函数调用的参数不一致时，还需要对Linux线程的函数调用的参数进行转换，转换为适用于 Windows线程中函数调用的参数。具体需要根据实际情况进行转换，如对 Linux线程的函数调用的参数进行处理，从中得到适用于Windows线程中函数调用的参数；或从系统中获得适用于Windows线程中函数调用的参数等等。
同时，由于线程中的全局变量与函数内定义的静态变量，是各个线程都可以访问的共享变量。因此，在线程中还涉及到线程局部存储(TLS，Thread Local Storage)。如果需要在一个线程内部的各个函数调用都能访问、但其它线程不能访问的变量时，就需要线程局部存储来实现。由于Linux线程与 Windows线程都有各自的线程局部存储，两种线程局部存储的数据结构、调用函数等不同，因此，线程功能转换模块110还需要对线程局部存储进行转换，将Linux线程的线程局部存储转换为Windows线程的线程局部存储。如涉及Linux线程与Windows线程的全局变量时，线程功能转换模块110还需要注意对全局变量的调用。Linux线程的全局变量保存在Linux线程的线程局部存储中，Windows线程的全局变量保存在Windows线程的线程局部存储中，线程功能转换模块110需要将Linux线程的线程局部存储转换为Windows线程的线程局部存储，以保证Linux线程中的全局变量变化对应的在Windows 线程中实现。
对于参数还需要注意，Linux线程中的参数压栈与Windows线程中的参数压栈处理不同，线程功能转换模块110在获取Linux线程中的参数向 Windows线程中传递时，还需要根据参数压栈处理的不同，进行相应的转换。
上述内容仅是举例说明，线程功能转换模块110在将Linux线程的处理功能转换为对应的Windows线程的处理功能时，需根据实际情况进行转换。
以上涉及Linux线程中的参数和全局变量等数据结构是否适用于 Windows线程的问题由线程数据结构转换模块120进一步处理。
线程数据结构转换模块120，适于解析Linux线程的数据结构，将Linux 线程适用的数据结构转换为对应的Windows线程适用的数据结构。
Linux线程中使用的数据结构和Windows线程中使用的数据结构存在不同之处。如Linux线程适用的参数数据结构、Linux线程适用的线程局部存储的数据结构等。
线程数据结构转换模块120在解析Linux线程的数据结构后，将Linux 线程适用的参数数据结构转换为对应的Windows线程适用的参数数据结构。如Linux线程中某函数调用的参数为long型，对应的Windows线程中函数调用的参数为Sting型，线程功能转换模块110不能直接将Linux线程中long 型参数传递给Windows线程中函数调用，需要线程数据结构转换模块120对 long型参数进行转换，将其转换为String型参数后，由线程功能转换模块110 将转换后的String型参数传递给Windows线程中函数调用。
进一步，若Linux线程中函数调用的参数个数与Windows线程中函数调用的参数个数不一致时，还需要线程数据结构转换模块120将Linux线程中函数调用的参数转换为Windows线程中函数调用的参数。如Windows线程中函数调用的参数都在Linux线程中函数调用的参数中存在时，线程数据结构转换模块120仅需将Windows线程中函数需要调用的对应的Linux线程中函数调用的参数的数据结构进行转换，线程功能转换模块110将转换后的对应的Linux线程中函数调用的参数传递给Windows线程中的函数。或 Windows线程中函数调用的参数在Linux线程中函数调用的参数中不存在时，线程功能转换模块110先将Linux线程中函数调用的参数进行转换，或通过其他手段获得Linux线程中所没有的Windows线程中函数所需的参数，再由线程数据结构转换模块120对所有的Windows线程中需要的参数的数据结构进行转换。
对于线程局部存储，线程数据结构转换模块120在解析Linux线程的数据结构后，将Linux线程适用的线程局部存储的数据结构转换为对应的 Windows线程适用的线程局部存储的数据结构。如对Linux线程中线程局部存储中所存储的全局变量和/或函数内定义的静态变量的数据结构，需要线程数据结构转换模块120将其对应的一一转换为Windows线程中线程局部存储的全局变量和/或函数内定义的静态变量的数据结构。
线程阻塞管理模块130，适于循环检测通过功能转换和数据结构转换运行于Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。
线程阻塞发生在线程执行过程中，由于某些条件阻止了线程的运行，而导致线程阻塞。当线程处于阻塞状态时，线程不会被分配任何的CPU时间，直到线程重新进入就绪状态，才有可能执行操作。或当两个线程彼此间相互调用时，造成死循环状态，导致两个线程均无法继续运行。因此，需对线程阻塞进行管理，避免因线程不能及时执行，导致的死锁、无响应等状况。
线程阻塞管理模块130循环检测Windows系统中的Windows线程，对 Windows线程的阻塞情况进行处理，以下就处理方式分别进行说明：
线程阻塞管理模块130创建独立的第一中间线程，第一中间线程用于循环检测Windows线程，如第一中间线程在Windows线程执行响应处理前，对Windows线程进行检测，检测Windows线程是否阻塞，若Windows线程无阻塞时，管理Windows线程执行响应处理。如检测Windows线程是否满足执行条件，若满足执行条件时，管理Windows线程执行响应处理。保证了无阻塞的Windows线程可以迅速的执行响应处理。
或者，线程阻塞管理模块130创建独立的第二中间线程，第二中间线程用于循环检测Windows线程。当第二中间线程检测到Windows线程阻塞时，首先暂停已经阻塞的Windows线程，将已经阻塞的Windows线程中的堆栈信息保存在第二中间线程中。然后强制使已经阻塞的Windows线程不再阻塞，执行响应处理。在Windows线程执行响应处理后，再恢复Windows线程中的阻塞的堆栈信息。或当第二中间线程检测到Windows线程阻塞时，强制使已经阻塞的Windows线程不再阻塞，使Windows线程继续执行。强制执行的办法根据实际情况设置，如模拟满足Windows线程可继续执行的条件等，此处不做具体限定。
进一步，由于Linux线程中还包括了对信号的处理，而Windows线程中没有对信号的处理，还需要线程功能转换模块110在Linux线程的信号被调用时，做相应的转换处理。如可将信号处理为在Windows线程上绑定的某种触发条件。当信号被调用时，即Windows线程的触发条件满足，执行相应的与信号相关的处理。线程阻塞管理模块130检测Windows线程上是否有信号被调用，当信号被调用时，Windows线程执行被调用的信号对应的相关处理函数。若Windows线程上所有的信号都没有被调用时，使Windows线程进入休眠，可休眠指定的时间。进一步，线程阻塞管理模块130还可以在 Windows线程休眠期间，对Windows线程做如自检、检测死锁等处理。
根据本发明提供的线程处理器，解析Linux线程的处理功能，将Linux 线程的处理功能转换为对应的Windows线程的处理功能。解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构。循环检测通过功能转换和数据结构转换运行于Windows系统中的 Windows线程，对Windows线程的阻塞情况进行处理。实现了在Windows 系统上处理Linux线程，且Linux线程在Windows系统上运行的效果如同在Linux系统上运行的效果，为Android应用程序在Windows系统上的运行提供了极大的便利。与在Windows系统安装Android虚拟机相比，极大的减少了系统资源的占用，无需用户执行复杂的安装操作，提供给用户更好的使用体验。同时，对Windows线程的阻塞情况进行及时有效的处理，减少了因线程阻塞、死循环等问题造成的内存被占用，运行速度慢等问题。
图2示出了根据本发明另一个实施例的线程处理器的功能框图。如图2 所示，线程处理器除包括如图1所示的模块外，还包括了内存处理模块140 和系统功能转换模块150。
内存处理模块140，适于实现Linux线程存储至Windows系统内存的存储功能及查找功能。具体地，由于Windows系统和Linux系统都有各自的存储规则，Linux线程存储到Windows系统的内存时，内存处理模块140按照 Windows系统内存的存储规则，根据Linux线程的请求找到满足其大小要求的连续地址的Windows空闲的内存空间，进行存储。内存处理模块140在存储后，还提供了查找的功能，根据Windows系统内存存储地址，从Windows 内存空间中找到Linux线程。
内存处理模块140进一步包括了跨页处理单元141，内存处理模块140 存储Linux线程时，Linux线程可能只需一页的Windows内存空间，也可能需要多页的Windows内存空间。当Linux线程需要多页的Windows内存空间，跨页处理单元141执行跨页处理。也就是说，Linux线程需要的空间超出了一页Windows内存空间的大小，在每页Windows内存空间的当前页空间不足以完成对Linux线程的存储要求时，即Windows系统内存中当前页空间不足的情况下，按照Windows系统内存页管理规则，跨页处理单元141执行了跨页处理，以完成对Windows系统的内存分配实现Linux线程的存储。跨页处理单元141在执行跨页处理时，还需要对已经分配的内存页空间进行标记。如标记内存页空间的使用状态(已使用的地址空间、剩余地址空间大小等等)、内存页空间的权限、各内存页空间地址信息、各内存页空间的链接顺序等等，方便了后续对Linux线程的查找。
内存处理模块140进一步包括了对齐单元142，适于按照Windows系统内存对齐规则，在Windows系统内存中当前字节空间不足的情况下，执行对齐处理，完成对Windows系统的内存分配。如Linux线程所请求的地址偏移不满足Windows字节的对齐要求，可能会导致在存储时，Windows系统的字节不能与Linux线程所请求的字节无法实现恰好的1对1或1对几的存储，出现Windows系统的字节在存储Linux线程部分内容后，留有一定的空间，而留下的空间不足以继续完成对Linux线程的存储的情况。对于这种情况，对齐单元142执行对齐处理，对Windows系统的内存进行分配，以完成对 Linux线程的存储。对齐单元142执行对齐处理时，还需要对已经分配的内存字节进行标记。如标记内存字节的使用状态(已使用的字节、剩余字节的大小等等)、内存字节的权限、各内存字节地址信息、各内存字节的链接顺序等等，方便了后续对Linux线程的查找。
系统功能转换模块150，适于将Linux系统函数功能转换为对应的 Windows函数功能。Linux线程所使用的系统函数为Linux系统函数，将Linux 线程在Windows系统上运行时，需要将这些Linux系统函数所实现的功能转换为对应的Windows系统函数功能。如将Linux系统下的printf、strlen、fopen 等函数转换为Windows系统下win32API中对应的函数。若Linux系统函数在Windows系统中没有对应的Windows系统函数时，系统功能转换模块150 还需要将其在Windows系统中进行重构，以Windows系统适用的函数进行实现。
根据本发明提供的线程处理器，完成了在Windows系统对Linux线程的存储和查找，并将Linux系统函数功能转换为对应的Windows函数功能，使得Linux线程在Windows系统上运行的效果如同在Linux系统上运行的效果，为Android应用程序在Windows系统上的运行提供了极大的便利。实现了对 Linux线程无修改的二进制级别的兼容。
图3示出了根据本发明另一个实施例的线程处理器的功能框图。如图3 所示，线程处理器除包括如图1所示的模块外，还包括了信号功能实现模块 160。
此处的信号为Linux信号，用于Linux线程中，是Linux线程间一种异步的通知机制，用于提醒Linux线程某一事件已经发生。Linux信号与其对应的信号处理函数进行挂接，当调用Linux信号时，执行其对应的信号处理函数。信号处理函数包括Linux系统中包含的系统级信号处理函数，如忽略该信号，也是一种信号处理函数的实现方法。还可以包括如用户通过调用 sigaction/signal等函数给Linux系统默认的信号或者用户自定义的Linux信号挂接自己实现的信号处理函数。调用Linux信号时，通过调用tkill等系统函数向指定的Linux线程发送指定的Linux信号，指定的Linux线程在接收到 Linux信号后，会相应的执行Linux信号挂接的信号处理函数。该信号处理函数可以为用户注册的或系统默认的信号处理函数。Linux信号有其完整的信号生命周期(从信号发送到相应的处理函数执行完毕)，包括：信号诞生、信号在线程中注册、信号的执行和注销等。
Linux系统中线程发送或接收信号都是基于Linux系统内核实现的， Windows系统不存在这样的实现机制。进一步，Linux信号是操作系统的一种机制，信号种类丰富，Linux信号的产生和处理不是连续的，信号的发生和处理是异步的。Windows信号是其CRT库所提供的一种功能，仅包含了有限的几种信号定义。Windows信号除某几个信号之外的其他信号都是同步的，即发生和处理在一起。当Linux线程在Windows系统中运行时，通过执行信号功能实现模块160将Linux信号与Linux信号的处理功能相对应的信号处理函数进行挂接；以及，将Linux信号处理涉及的函数转换为对应的Windows 函数，以实现Linux线程上的Linux信号在Windows系统上相应的功能处理。
Linux信号创建后，信号功能实现模块160通过如sigaction/signal等函数里先将Linux信号与Linux信号对应的信号处理函数进行挂接，并将Linux 信号和其对应的信号处理函数转换为Windows系统上相应的功能实现，将其存储在线程对应的线程局部存储中。该线程为转换后的Windows线程，该线程对应的线程局部存储为转换后的线程局部存储。
若某Linux信号被调用时，信号功能实现模块160通过如tkill等函数，将需要发送的Linux信号以及Linux信号所绑定的线程存储在该线程的线程局部存储中。再从该线程中查找到对应的Linux信号。在找到对应的Linux 信号后，执行其处理功能相对应的信号处理函数。该信号处理函数为信号功能实现模块160转换的对应的Windows函数。以上仅为举例说明，Linux信号处理涉及的函数至少包含创建信号函数、查找信号函数、信号处理函数。除此之外，Linux系统中相关的信号函数在实际实施时若需要被使用时，都需要通过信号功能实现模块160转换为对应的Windows函数。
其中Linux信号处理涉及的函数中包含的参数、变量等数据结构的转换，可以通过线程数据结构转换模块120进行相应的转换。
同时，线程阻塞管理模块130还可以创建独立的信号检查线程，用于遍历检查其它线程的线程局部存储所存储的内容中是否有信号被调用。根据被调用信号的类型和所检查的线程的类型来确定对信号调用的处理方式。处理时，可以包括如检查的线程为内核级别可自中断的线程时，通过调用Windows 系统的Asynchronous Procedure Calls接口函数执行相应的处理。或检查的线程为内核级别且Windows系统无法自中断的线程时，通过调用SuspendThread 等接口函数主动暂停该线程，将该线程保存寄存器线程后，调用信号对应的信号处理函数，再恢复寄存器线程。而后调用ResumeThread接口函数恢复该线程，使该线程继续执行。线程阻塞管理模块130还可以包括信号自检函数。若检测的线程为用户级别线程，可执行如sleep之类可自行中断的函数时，通过线程阻塞管理模块130可内置信号自检函数，自我检查线程的线程局部存储，当信号被调用后即时执行对应的信号处理函数。线程阻塞管理模块130 的该检测方式可直接在线程上进行实施。
进一步，图3也可以包括图2所示的内存处理模块140和系统功能转换模块150(图中未示出)。这些模块的描述可以参考上面的实施例，在此不再赘述。
根据本发明提供的线程处理器，完成了在Windows系统对Linux线程在 Linux信号的实现，使得Linux线程在Windows系统上运行的效果如同在 Linux系统上运行的效果，为Android应用程序在Windows系统上的运行提供了极大的便利，实现了对Linux线程无修改的二进制级别的兼容。
图4示出了根据本发明一个实施例的线程处理方法的流程图，方法基于 Windows系统实现对Linux线程的处理，如图4所示，线程处理方法具体包括如下步骤：
步骤S11，线程功能转换步骤，解析Linux线程的处理功能，将Linux 线程的处理功能转换为对应的Windows线程的处理功能。
Linux线程中调用的为适用于Linux系统的各种函数，这些函数无法在 Windows系统上直接执行，需要执行线程功能转换步骤先对其实现的功能进行转换。转换时使用在Windows系统上适用的函数进行相应的功能替换。
解析Linux线程的处理功能后，需要找到与实现Linux线程的处理功能的一个或多个函数相对应的Windows线程使用的函数，并根据Linux线程中函数的调用顺序或功能处理的顺序，依次调用对应的Windows线程使用的函数。若实现Linux线程的处理功能的一个或多个函数在Windows系统中没有其对应的函数，还需要将该一个或多个函数的功能在Windows系统上完成对应的实现，并将该实现函数与其他对应的Windows线程使用的函数按照 Linux线程中函数的调用顺序或功能处理的顺序进行调用。如某个Linux线程 A，其中，Linux线程A包括调用函数A1、函数A2、函数A3。转换时调用对应的Windows系统中的函数B1、函数B2、函数B3。其中，函数B1实现了函数A1中的功能，函数B2实现了函数A2中的功能，函数B3实现了函数A3中的功能。或函数B2实现了函数A2和函数A3中的功能，转换时仅调用对应的Windows系统中的函数B1和函数B2。或者，Windows系统中没有与函数A1实现的功能对应的方法，还需要将函数A1实现的功能进行实现，在实现函数A1对应的功能后，进一步调用Windows系统中实现了函数A2 和函数A3中功能所对应的方法。
进一步，在调用对应的Windows线程的函数时，需要注意函数中调用的参数，传递正确的参数以便Windows线程的函数进行调用。如Windows线程中函数调用的参数与Linux线程的函数调用的参数不一致时，还需要对 Linux线程的函数调用的参数进行转换，转换为适用于Windows线程中函数调用的参数。具体需要根据实际情况进行转换，如对Linux线程的函数调用的参数进行处理，从中得到适用于Windows线程中函数调用的参数；或从系统中获得适用于Windows线程中函数调用的参数等等。
同时，由于线程中的全局变量与函数内定义的静态变量，是各个线程都可以访问的共享变量。因此，在线程中还涉及到线程局部存储(TLS，Thread Local Storage)。如果需要在一个线程内部的各个函数调用都能访问、但其它线程不能访问的变量时，就需要线程局部存储来实现。由于Linux线程与 Windows线程都有各自的线程局部存储，两种线程局部存储的数据结构、调用函数等不同，因此，转换时还需要对线程局部存储进行转换，将Linux线程的线程局部存储转换为Windows线程的线程局部存储。如涉及Linux线程与Windows线程的全局变量时，需要注意对全局变量的调用。Linux线程的全局变量保存在Linux线程的线程局部存储中，Windows线程的全局变量保存在Windows线程的线程局部存储中，转换时需要将Linux线程的线程局部存储转换为Windows线程的线程局部存储，以保证Linux线程中的全局变量变化对应的在Windows线程中实现。
对于参数还需要注意，Linux线程中的参数压栈与Windows线程中的参数压栈处理不同，在获取Linux线程中的参数向Windows线程中传递时，还需要根据参数压栈处理的不同，进行相应的转换。
上述内容仅是举例说明，在将Linux线程的处理功能转换为对应的 Windows线程的处理功能时，需根据实际情况进行转换。
以上涉及Linux线程中的参数和全局变量等数据结构是否适用于 Windows线程的问题由步骤S12进一步处理。
步骤S12，线程数据结构转换步骤，解析Linux线程的数据结构，将Linux 线程适用的数据结构转换为对应的Windows线程适用的数据结构。
Linux线程中使用的数据结构和Windows线程中使用的数据结构存在不同之处。如Linux线程适用的参数数据结构、Linux线程适用的线程局部存储的数据结构等。
在解析Linux线程的数据结构后，将Linux线程适用的参数数据结构转换为对应的Windows线程适用的参数数据结构。如Linux线程中某函数调用的参数为long型，对应的Windows线程中函数调用的参数为Sting型，执行步骤S11时不能直接将Linux线程中long型参数传递给Windows线程中函数调用，需要先对long型参数进行转换，将其转换为String型参数后，再执行步骤S11将转换后的String型参数传递给Windows线程中函数调用。
进一步，若Linux线程中函数调用的参数个数与Windows线程中函数调用的参数个数不一致时，还需要将Linux线程中函数调用的参数转换为 Windows线程中函数调用的参数。如Windows线程中函数调用的参数都在 Linux线程中函数调用的参数中存在时，仅需将Windows线程中函数需要调用的对应的Linux线程中函数调用的参数的数据结构进行转换，再执行步骤 S11将转换后的对应的Linux线程中函数调用的参数传递给Windows线程中的函数。或Windows线程中函数调用的参数在Linux线程中函数调用的参数中不存在时，先执行步骤S11先将Linux线程中函数调用的参数进行转换，或通过其他手段获得Linux线程中所没有的Windows线程中函数所需的参数，再对所有的Windows线程中需要的参数的数据结构进行转换。
对于线程局部存储，在解析Linux线程的数据结构后，将Linux线程适用的线程局部存储的数据结构转换为对应的Windows线程适用的线程局部存储的数据结构。如对Linux线程中线程局部存储中所存储的全局变量和/或函数内定义的静态变量的数据结构，需要将其对应的一一转换为Windows线程中线程局部存储的全局变量和/或函数内定义的静态变量的数据结构。
以上步骤S11和S12执行时，如上述举例中所提的，可能先执行S11，也可能先执行S12。具体需要根据实际的情况去执行，此处不设定具体的执行前后顺序。
步骤S13，线程阻塞管理步骤，循环检测通过功能转换和数据结构转换运行于Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。
线程阻塞发生在线程执行过程中，由于某些条件阻止了线程的运行，而导致线程阻塞。当线程处于阻塞状态时，线程不会被分配任何的CPU时间，直到线程重新进入就绪状态，才有可能执行操作。或当两个线程彼此间相互调用时，造成死循环状态，导致两个线程均无法继续运行。因此，需对线程阻塞进行管理，避免因线程不能及时执行，导致的死锁、无响应等状况。
因此，针对Windows线程的阻塞情况，进行了处理，以下就处理方式分别进行说明：
线程阻塞管理步骤进一步包括创建独立的第一中间线程，第一中间线程用于循环检测Windows线程，如第一中间线程在Windows线程执行响应处理前，对Windows线程进行检测，检测Windows线程是否阻塞，若Windows 线程无阻塞时，管理Windows线程执行响应处理。如检测Windows线程是否满足执行条件，若满足执行条件时，管理Windows线程执行响应处理。保证了无阻塞的Windows线程可以迅速的执行响应处理。
或者，线程阻塞管理步骤进一步包括创建独立的第二中间线程，第二中间线程用于循环检测Windows线程。当第二中间线程检测到Windows线程阻塞时，首先暂停已经阻塞的Windows线程，将已经阻塞的Windows线程中的堆栈信息保存在第二中间线程中。然后强制使已经阻塞的Windows线程不再阻塞，执行响应处理。在Windows线程执行响应处理后，再恢复Windows 线程中的阻塞的堆栈信息。或当第二中间线程检测到Windows线程阻塞时，强制使已经阻塞的Windows线程不再阻塞，使Windows线程继续执行。强制执行的办法根据实际情况设置，如模拟满足Windows线程可继续执行的条件等，此处不做具体限定。
进一步，由于Linux线程中还包括了对信号的处理，而Windows线程中没有对信号的处理，还需要执行步骤S11在Linux线程的信号被调用时，做相应的转换处理。如可将信号处理为在Windows线程上绑定的某种触发条件。当信号被调用时，即Windows线程的触发条件满足，执行相应的与信号相关的处理。线程阻塞管理步骤进一步包括：检测Windows线程上是否有信号被调用，当信号被调用时，Windows线程执行被调用的信号对应的相关处理函数。若Windows线程上所有的信号都没有被调用时，使Windows线程进入休眠，可休眠指定的时间。进一步，还可以在Windows线程休眠期间，对Windows线程做如自检、检测死锁等处理。
当Linux线程中没有涉及数据结构转换时，即不需要执行步骤S12时，步骤S13的执行可在步骤S11后直接执行。步骤S13也可以在执行步骤S11 和S12后执行。具体执行时需根据实际情况执行各步骤，此处不对步骤做先后顺序的限定。
根据本发明提供的线程处理方法，解析Linux线程的处理功能，将Linux 线程的处理功能转换为对应的Windows线程的处理功能。解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构。循环检测通过功能转换和数据结构转换运行于Windows系统中的 Windows线程，对Windows线程的阻塞情况进行处理。实现了在Windows 系统上处理Linux线程，且Linux线程在Windows系统上运行的效果如同在Linux系统上运行的效果，为Android应用程序在Windows系统上的运行提供了极大的便利。与在Windows系统安装Android虚拟机相比，极大的减少了系统资源的占用，无需用户执行复杂的安装操作，提供给用户更好的使用体验。同时，对Windows线程的阻塞情况进行及时有效的处理，减少了因线程阻塞、死循环等问题造成的内存被占用，运行速度慢等问题。
图5示出了根据本发明另一个实施例的线程处理方法的流程图，方法基于Windows系统实现对Linux线程的处理，如图5所示，线程处理方法具体包括如下步骤：
步骤S21，线程功能转换步骤，解析Linux线程的处理功能，将Linux 线程的处理功能转换为对应的Windows线程的处理功能。
步骤S22，线程数据结构转换步骤，解析Linux线程的数据结构，将Linux 线程适用的数据结构转换为对应的Windows线程适用的数据结构。
步骤S23，线程阻塞管理步骤，循环检测通过功能转换和数据结构转换运行于Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。
以上步骤说明参照图4中方法实施例的说明，在此不再赘述。
步骤S24，内存处理步骤，实现Linux线程存储至Windows系统内存的存储功能及查找功能。
具体地，由于Windows系统和Linux系统都有各自的存储规则，Linux 线程存储到Windows系统的内存时，需要按照Windows系统内存的存储规则，根据Linux线程的请求找到满足其大小要求的连续地址的Windows空闲的内存空间，进行存储。在存储后，还提供了查找的功能，根据Windows系统内存存储地址，从Windows内存空间中找到Linux线程。
存储Linux线程时，Linux线程可能只需一页的Windows内存空间，也可能需要多页的Windows内存空间。当Linux线程需要多页的Windows内存空间，内存处理步骤进一步包括了执行跨页处理。也就是说，Linux线程需要的空间超出了一页Windows内存空间的大小，在每页Windows内存空间的当前页空间不足以完成对Linux线程的存储要求时，即Windows系统内存中当前页空间不足的情况下，按照Windows系统内存页管理规则，执行跨页处理，以完成对Windows系统的内存分配实现Linux线程的存储。同时，在执行跨页处理时，还需要对已经分配的内存页空间进行标记。如标记内存页空间的使用状态(已使用的地址空间、剩余地址空间大小等等)、内存页空间的权限、各内存页空间地址信息、各内存页空间的链接顺序等等，方便了后续对Linux线程的查找。
内存处理步骤进一步包括按照Windows系统内存对齐规则，在Windows 系统内存中当前字节空间不足的情况下，执行对齐处理，完成对Windows系统的内存分配。如Linux线程所请求的地址偏移不满足Windows字节的对齐要求，可能会导致在存储时，Windows系统的字节不能与Linux线程所请求的字节无法实现恰好的1对1或1对几的存储，出现Windows系统的字节在存储Linux线程部分内容后，留有一定的空间，而留下的空间不足以继续完成对Linux线程的存储的情况。对于这种情况，执行对齐处理，对Windows 系统的内存进行分配，以完成对Linux线程的存储。同时，执行对齐处理时，还需要对已经分配的内存字节进行标记。如标记内存字节的使用状态(已使用的字节、剩余字节的大小等等)、内存字节的权限、各内存字节地址信息、各内存字节的链接顺序等等，方便了后续对Linux线程的查找。
步骤S25，系统功能转换步骤，将Linux系统函数功能转换为对应的 Windows系统函数功能。
Linux线程所使用的系统函数为Linux系统函数，将Linux线程在 Windows系统上运行时，需要将这些Linux系统函数所实现的功能转换为对应的Windows系统函数功能。如将Linux系统下的printf、strlen、fopen等函数转换为Windows系统下win32API中对应的函数。若Linux系统函数在 Windows系统中没有对应的Windows系统函数时，还需要将其在Windows 系统中进行重构，以Windows系统适用的函数进行实现。
在此需要注意的时，步骤S21-步骤S25各步骤之间不存在单一限定的前后执行顺序，具体执行时需根据实际情况执行各步骤，此处不对步骤做先后顺序的限定。
根据本发明提供的线程处理方法，完成了在Windows系统对Linux线程的存储和查找，并将Linux系统函数功能转换为对应的Windows函数功能，使得Linux线程在Windows系统上运行的效果如同在Linux系统上运行的效果，为Android应用程序在Windows系统上的运行提供了极大的便利。实现了对Linux线程无修改的二进制级别的兼容。
图5示出了根据本发明另一个实施例的线程处理方法的流程图，方法基于Windows系统实现对Linux线程的处理，如图6所示，线程处理方法具体包括如下步骤：
步骤S31，线程功能转换步骤，解析Linux线程的处理功能，将Linux 线程的处理功能转换为对应的Windows线程的处理功能。
步骤S32，线程数据结构转换步骤，解析Linux线程的数据结构，将Linux 线程适用的数据结构转换为对应的Windows线程适用的数据结构。
步骤S33，线程阻塞管理步骤，循环检测通过功能转换和数据结构转换运行于Windows系统中的Windows线程，对Windows线程的阻塞情况进行处理。
以上步骤说明参照图4中方法实施例的说明，在此不再赘述。
步骤S34，信号功能实现步骤，将Linux信号与Linux信号的处理功能相对应的信号处理函数进行挂接；以及，将Linux信号处理涉及的函数转换为对应的Windows函数。
此处的信号为Linux信号，用于Linux线程中，是Linux线程间一种异步的通知机制，用于提醒Linux线程某一事件已经发生。Linux信号与其对应的信号处理函数进行挂接，当调用Linux信号时，执行其对应的信号处理函数。信号处理函数包括Linux系统中包含的系统级信号处理函数，如忽略该信号，也是一种信号处理函数的实现方法。还可以包括如用户通过调用 sigaction/signal等函数给Linux系统默认的信号或者用户自定义的Linux信号挂接自己实现的信号处理函数。调用Linux信号时，通过调用tkill等系统函数向指定的Linux线程发送指定的Linux信号，指定的Linux线程在接收到 Linux信号后，会相应的执行Linux信号挂接的信号处理函数。该信号处理函数可以为用户注册的或系统默认的信号处理函数。Linux信号有其完整的信号生命周期(从信号发送到相应的处理函数执行完毕)，包括：信号诞生、信号在线程中注册、信号的执行和注销等。
Linux系统中线程发送或接收信号都是基于Linux系统内核实现的， Windows系统不存在这样的实现机制。进一步，Linux信号是操作系统的一种机制，信号种类丰富，Linux信号的产生和处理不是连续的，信号的发生和处理是异步的。Windows信号是其CRT库所提供的一种功能，仅包含了有限的几种信号定义。Windows信号除某几个信号之外的其他信号都是同步的，即发生和处理在一起。当Linux线程在Windows系统中运行时，通过执行信号功能实现步骤将Linux信号与Linux信号的处理功能相对应的信号处理函数进行挂接；以及，将Linux信号处理涉及的函数转换为对应的Windows函数，以实现Linux线程上的Linux信号在Windows系统上相应的功能处理。
Linux信号创建后，通过如sigaction/signal等函数里先将Linux信号与 Linux信号对应的信号处理函数进行挂接，并将Linux信号和其对应的信号处理函数转换为Windows系统上相应的功能实现，将其存储在线程对应的线程局部存储中。该线程为转换后的Windows线程，该线程对应的线程局部存储为转换后的线程局部存储。
若某Linux信号被调用时，通过如tkill等函数，将需要发送的Linux信号以及Linux信号所绑定的线程存储在该线程的线程局部存储中。再从该线程中查找到对应的Linux信号。在找到对应的Linux信号后，执行其处理功能相对应的信号处理函数。该信号处理函数为转换后的对应的Windows函数。以上仅为举例说明，Linux信号处理涉及的函数至少包含创建信号函数、查找信号函数、信号处理函数。除此之外，Linux系统中相关的信号函数在实际实施时若需要被使用时，都需要转换为对应的Windows函数实现相应的 Linux信号的功能。
其中Linux信号处理涉及的函数中包含的参数、变量等数据结构的转换，可以通过线程数据结构转换步骤进行相应的转换。
同时，线程阻塞管理步骤中还包括创建独立的信号检查线程，用于遍历检查其它线程的线程局部存储所存储的内容中是否有信号被调用。根据被调用信号的类型和所检查的线程的类型来确定对信号调用的处理方式。处理时，可以包括如检查的线程为内核级别可自中断的线程时，通过调用Windows系统的Asynchronous Procedure Calls接口函数执行相应的处理。或检查的线程为内核级别且Windows系统无法自中断的线程时，通过调用SuspendThread 等接口函数主动暂停该线程，将该线程保存寄存器线程后，调用信号对应的信号处理函数，再恢复寄存器线程。而后调用ResumeThread接口函数恢复该线程，使该线程继续执行。线程阻塞管理步骤还可以包括信号自检函数。若检测的线程为用户级别线程，可执行如sleep之类可自行中断的函数时，通过线程阻塞管理步骤可内置信号自检函数，自我检查线程的线程局部存储，当信号被调用后即时执行对应的信号处理函数。线程阻塞管理步骤的该检测方式可直接在线程上进行实施。
进一步，图6也可以包括图5所示的步骤S24和步骤S25(图中未示出)，步骤S24和步骤S25的描述可以参考上面的实施例，在此不再赘述。在此需要注意的时，各步骤之间不存在单一限定的前后执行顺序，具体执行时需根据实际情况执行各步骤，此处不对步骤做先后顺序的限定。
根据本发明提供的线程处理方法，完成了在Windows系统对Linux线程在Linux信号的实现，使得Linux线程在Windows系统上运行的效果如同在 Linux系统上运行的效果，为Android应用程序在Windows系统上的运行提供了极大的便利，实现了对Linux线程无修改的二进制级别的兼容。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的线程处理器中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (20)

1.一种线程处理器，所述线程处理器基于Windows系统实现对Linux线程的处理，所述线程处理器包括：
线程功能转换模块，适于解析Linux线程的处理功能，将Linux线程的处理功能转换为对应的Windows线程的处理功能；
线程数据结构转换模块，适于解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构；
线程阻塞管理模块，适于循环检测通过功能转换和数据结构转换运行于Windows系统中的Windows线程，对所述Windows线程的阻塞情况进行处理；
所述线程阻塞管理模块进一步适于：
检测所述Windows线程上是否有信号被调用；
若是，执行被调用的信号对应的相关处理函数；
否则，使所述Windows线程休眠指定时间。
2.根据权利要求1所述的线程处理器，其中，所述线程阻塞管理模块进一步适于：
创建第一中间线程，所述第一中间线程用于循环检测Windows线程，管理无阻塞的Windows线程执行响应处理。
3.根据权利要求1所述的线程处理器，其中，所述线程阻塞管理模块进一步适于：
创建第二中间线程，所述第二中间线程用于循环检测Windows线程，在所述Windows线程阻塞情况下，暂停所述Windows线程，保存所述Windows线程中的阻塞的堆栈信息，强制所述Windows线程执行响应处理后，恢复所述Windows线程中的阻塞的堆栈信息。
4.根据权利要求1-3任一项所述的线程处理器，其中，所述线程处理器还包括：
内存处理模块，适于实现Linux线程存储至Windows系统内存的存储功能及查找功能。
5.根据权利要求4所述的线程处理器，其中，所述内存处理模块进一步包括：
跨页处理单元，适于按照Windows系统内存页管理规则，在Windows系统内存中当前页空间不足的情况下，执行跨页处理，完成对Windows系统的内存分配。
6.根据权利要求4所述的线程处理器，其中，所述内存处理模块进一步包括：
对齐单元，适于按照Windows系统内存对齐规则，在Windows系统内存中当前字节空间不足的情况下，执行对齐处理，完成对Windows系统的内存分配。
7.根据权利要求1所述的线程处理器，其中，所述线程数据结构转换模块进一步适于：
将Linux线程适用的参数数据结构转换为对应的Windows线程适用的参数数据结构。
8.根据权利要求1所述的线程处理器，其中，所述线程数据结构转换模块进一步适于：
将Linux线程适用的线程局部存储的数据结构转换为对应的Windows线程适用的线程局部存储的数据结构。
9.根据权利要求1-3任一项所述的线程处理器，其中，所述线程处理器还包括：
系统功能转换模块，适于将Linux系统函数功能转换为对应的Windows系统函数功能。
10.根据权利要求1-3任一项所述的线程处理器，其中，所述线程处理器还包括：
信号功能实现模块，适于将Linux信号与Linux信号的处理功能相对应的信号处理函数进行挂接；以及，将Linux信号处理涉及的函数转换为对应的Windows函数，所述Linux信号处理涉及的函数至少包含创建信号函数、所述信号处理函数以及查找信号函数。
11.一种线程处理方法，所述方法基于Windows系统实现对Linux线程的处理，所述方法包括：
线程功能转换步骤，解析Linux线程的处理功能，将Linux线程的处理功能转换为对应的Windows线程的处理功能；
线程数据结构转换步骤，解析Linux线程的数据结构，将Linux线程适用的数据结构转换为对应的Windows线程适用的数据结构；
线程阻塞管理步骤，循环检测通过功能转换和数据结构转换运行于Windows系统中的Windows线程，对所述Windows线程的阻塞情况进行处理；
所述线程阻塞管理步骤进一步包括：
检测所述Windows线程上是否有信号被调用；
若是，执行被调用的信号对应的相关处理函数；
否则，使所述Windows线程休眠指定时间。
12.根据权利要求11所述的线程处理方法，其中，所述线程阻塞管理步骤进一步包括：
创建第一中间线程，所述第一中间线程用于循环检测Windows线程，管理无阻塞的Windows线程执行响应处理。
13.根据权利要求11所述的线程处理方法，其中，所述线程阻塞管理步骤进一步包括：
创建第二中间线程，所述第二中间线程用于循环检测Windows线程，在所述Windows线程阻塞情况下，暂停所述Windows线程，保存所述Windows线程中的阻塞的堆栈信息，强制所述Windows线程执行响应处理后，恢复所述Windows线程中的阻塞的堆栈信息。
14.根据权利要求11-13任一项所述的线程处理方法，其中，所述方法还包括：
内存处理步骤，实现Linux线程存储至Windows系统内存的存储功能及查找功能。
15.根据权利要求14所述的线程处理方法，其中，所述内存处理步骤进一步包括：
按照Windows系统内存页管理规则，在Windows系统内存中当前页空间不足的情况下，执行跨页处理，完成对Windows系统的内存分配。
16.根据权利要求14所述的线程处理方法，其中，所述内存处理步骤进一步包括：
按照Windows系统内存对齐规则，在Windows系统内存中当前字节空间不足的情况下，执行对齐处理，完成对Windows系统的内存分配。
17.根据权利要求11所述的线程处理方法，其中，所述线程数据结构转换步骤进一步包括：
将Linux线程适用的参数数据结构转换为对应的Windows线程适用的参数数据结构。
18.根据权利要求11所述的线程处理方法，其中，所述线程数据结构转换步骤进一步包括：
将Linux线程适用的线程局部存储的数据结构转换为对应的Windows线程适用的线程局部存储的数据结构。
19.根据权利要求11-13任一项所述的线程处理方法，其中，所述方法还包括：
系统功能转换步骤，将Linux系统函数功能转换为对应的Windows系统函数功能。
20.根据权利要求11-13任一项所述的线程处理方法，其中，所述方法还包括：
信号功能实现步骤，将Linux信号与Linux信号的处理功能相对应的信号处理函数进行挂接；以及，将Linux信号处理涉及的函数转换为对应的Windows函数，所述Linux信号处理涉及的函数至少包含创建信号函数、所述信号处理函数以及查找信号函数。
CN201610797409.XA 2016-08-31 2016-08-31 线程处理器及线程处理方法 Active CN106371809B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201610797409.XA CN106371809B (zh) 2016-08-31 2016-08-31 线程处理器及线程处理方法
US15/741,133 US20190087221A1 (en) 2016-08-31 2016-10-31 Thread processor and thread processing method
PCT/CN2016/104062 WO2018040271A1 (zh) 2016-08-31 2016-10-31 线程处理器及线程处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610797409.XA CN106371809B (zh) 2016-08-31 2016-08-31 线程处理器及线程处理方法

Publications (2)

Publication Number Publication Date
CN106371809A CN106371809A (zh) 2017-02-01
CN106371809B true CN106371809B (zh) 2019-03-01

Family

ID=57899151

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610797409.XA Active CN106371809B (zh) 2016-08-31 2016-08-31 线程处理器及线程处理方法

Country Status (3)

Country Link
US (1) US20190087221A1 (zh)
CN (1) CN106371809B (zh)
WO (1) WO2018040271A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109960659B (zh) * 2019-03-29 2022-11-01 阿波罗智联(北京)科技有限公司 用于检测应用程序的方法和装置
CN112181609B (zh) * 2019-07-05 2024-04-26 浙江宇视科技有限公司 服务守护方法、装置及可读存储介质
CN112749017A (zh) * 2019-10-31 2021-05-04 中兴通讯股份有限公司 移动通信方法及装置、存储介质、电子装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102117240A (zh) * 2009-12-31 2011-07-06 腾讯科技（深圳）有限公司 一种获取进程阻塞信息的方法及装置
CN103077076A (zh) * 2013-01-06 2013-05-01 北京航空航天大学 在Linux上模拟实现Windows堆管理的方法
CN103365665A (zh) * 2013-07-25 2013-10-23 成都品果科技有限公司 一种基于虚拟指令的应用程序移植方法
CN104360839A (zh) * 2014-10-20 2015-02-18 浪潮电子信息产业股份有限公司 自动从linux系统迁移到windows系统的方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020049867A1 (en) * 2000-08-29 2002-04-25 Yoshitomo Kumagai Application transfer method, application transfer system and storage medium therefore
CN1731347A (zh) * 2004-08-06 2006-02-08 梁肇新 基于Linux的Windows软件兼容层体系结构
WO2006018307A2 (en) * 2004-08-18 2006-02-23 Jaluna Sa Operating systems
US20060070069A1 (en) * 2004-09-30 2006-03-30 International Business Machines Corporation System and method for sharing resources between real-time and virtualizing operating systems
US8195624B2 (en) * 2005-06-30 2012-06-05 Phoenix Technologies Ltd. Shared file system management between independent operating systems
US20070050770A1 (en) * 2005-08-30 2007-03-01 Geisinger Nile J Method and apparatus for uniformly integrating operating system resources
US7769962B2 (en) * 2005-12-12 2010-08-03 Jeda Technologies, Inc. System and method for thread creation and memory management in an object-oriented programming environment
CN101630258A (zh) * 2009-07-29 2010-01-20 精伦电子股份有限公司 Windows平台上嵌入式Linux软件集成开发系统及其构建方法
CN102073532A (zh) * 2010-12-29 2011-05-25 浙大网新科技股份有限公司 在Linux内核中实现仿Windows系统调用机制的方法
CN102455938B (zh) * 2011-11-16 2013-04-24 中标软件有限公司 一种在mips版本的linux操作系统上运行windows应用软件的方法
US10067768B2 (en) * 2014-07-18 2018-09-04 Nvidia Corporation Execution of divergent threads using a convergence barrier

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102117240A (zh) * 2009-12-31 2011-07-06 腾讯科技（深圳）有限公司 一种获取进程阻塞信息的方法及装置
CN103077076A (zh) * 2013-01-06 2013-05-01 北京航空航天大学 在Linux上模拟实现Windows堆管理的方法
CN103365665A (zh) * 2013-07-25 2013-10-23 成都品果科技有限公司 一种基于虚拟指令的应用程序移植方法
CN104360839A (zh) * 2014-10-20 2015-02-18 浪潮电子信息产业股份有限公司 自动从linux系统迁移到windows系统的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Windows程序运行于Linux系统的技术;王亚军等;《计算机应用》;20090831;第29卷(第8期);正文第2129页

Also Published As

Publication number Publication date
US20190087221A1 (en) 2019-03-21
WO2018040271A1 (zh) 2018-03-08
CN106371809A (zh) 2017-02-01

Similar Documents

Publication Publication Date Title
US20210081258A1 (en) Synthesis Path For Transforming Concurrent Programs Into Hardware Deployable on FPGA-Based Cloud Infrastructures
CN104915285B (zh) 一种容器进程监控方法、装置及系统
CN106302008B (zh) 数据更新方法和装置
CN106357738B (zh) 一种服务器集群的自动化部署方法、装置和系统
CN105630543B (zh) 一种应用冷启动加速的方法及装置
EP2082318B1 (en) Register-based instruction optimization for facilitating efficient emulation of an instruction stream
CN106371809B (zh) 线程处理器及线程处理方法
CN109800159A (zh) 程序调试方法、程序调试装置、终端设备及存储介质
CN106844153B (zh) 应用程序运行监控方法、装置以及终端
CN105204917B (zh) 在应用程序启动时加载配置文件的方法及装置
CN105471968B (zh) 一种数据交换方法、系统以及数据平台服务器
WO2015008115A1 (en) Method and computer program product for disassembling a mixed machine code
CN105630927B (zh) 链接生成方法和装置
CN110069259A (zh) 基于idl文件的解析方法、装置、电子设备和存储介质
CN109445880A (zh) 跨线程调用链上下文的传递方法、装置及电子设备
CN109739704A (zh) 一种接口测试方法、服务端及计算机可读存储介质
US8887142B2 (en) Loop control flow diversion
CN110135940A (zh) 后厨订单显示装置及方法
CN108920295A (zh) 系统异常的处理方法、装置及系统
CN105204907B (zh) 浏览器启动方法和装置
CN104915288A (zh) 测试方法及装置
CN110399275A (zh) 异常展示方法及装置
CN103501251B (zh) 断网情况下的数据包处理方法及装置
CN109460215A (zh) 应用控制方法及装置
CN108062224A (zh) 基于文件句柄的数据读写方法、装置及计算设备

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20220706

Address after: Room 801, 8th floor, No. 104, floors 1-19, building 2, yard 6, Jiuxianqiao Road, Chaoyang District, Beijing 100015

Patentee after: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Address before: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park)

Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Patentee before: Qizhi software (Beijing) Co.,Ltd.

TR01 Transfer of patent right