Apparatus, system, and method for persistent user-level thread

Embodiments of the invention provide a method of creating, based on an operating-system-scheduled thread running on an operating-system-visible sequencer and using an instruction set extension, a persistent user-level thread to run on an operating-system-sequestered sequencer independently of context switch activities on the operating-system-scheduled thread. The operating-system-scheduled thread and the persistent user-level thread may share a common virtual address space. Embodiments of the invention may also provide a method of causing a service thread running on an additional operating-system-visible sequencer to provide operating system services to the persistent user-level thread. Embodiments of the invention may further provide apparatus, system, and machine-readable medium thereof.

BACKGROUND OF THE INVENTION

In a multi-sequencer computer system or computer platform, technical as well as economic constraints may justify an asymmetric organization of specialized computing resources or processors or processing units. In this application, a processor or processing unit may also be referred to, hereinafter, as a sequencer or a processing core. In general, an operating system may not scale well on a computer platform having implemented a large number of sequencers. In particular, the operating system may not be able to handle an asymmetric organization of multiple sequencers efficiently.

The organization of a computer platform may be asymmetric with regard to the types of sequencers that the platform has implemented. For example, there may be sequencers that are “visible” to the operating system (OS), referred to herein as OS-visible sequencers, and are managed by OS kernels. The OS kernels may be able to control the privilege states of OS-visible sequencers and to provide exception handlers to process interrupts and/or exceptions during execution of threads by the OS-visible sequencers. On the other hand, there may be sequencers that are “invisible” to the OS, referred to herein as OS-sequestered sequencers. OS-sequestered sequencers may not execute operating system codes and may be managed by a sequencer manager.

Recently, a multi-sequencer multiple-instruction-flow-multiple-dataflow (MIMD) ISA (Instruction Set Architecture) extension has been proposed that defines a set of instructions allowing OS-sequestered sequencers to be treated as ring-3 user-level architectural resources for concurrent execution of multiple user-level threads in the single OS thread context. Therefore, OS-sequestered sequencers become available to user-level applications. By using the user-level multi-sequencer MIMD ISA extension, an application thread running on an OS-visible sequencer may be able to use the additional sequencers which are sequestered from the OS. The multi-sequencer MIMD ISA extension allows applications to scale, independent of the OS, for a large number of sequencers by submitting work to sequencers that may or may not be visible to the operating system. In the mean time, the operating system may continue to run on a subset of sequencers that are visible to the OS. The user-level MIMD ISA extension allows execution of user-level threads to run on OS-sequestered sequencers, and the user-level threads may run concurrently with the OS thread that created the user-level threads and runs on an OS-visible sequencer.

It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Some portions of the detailed description in the following are presented in terms of algorithms and symbolic representations of operations on data bits or binary digital signals within a computer memory. These algorithmic descriptions and representations may be the techniques used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art.

Some embodiments of the invention may be implemented, for example, using a machine-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, cause the machine to perform a method and/or operations in accordance with embodiments of the invention. Such machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, e.g., memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, various types of Digital Versatile Disks (DVDs), a tape, a cassette, or the like. The instructions may include any suitable type of code, for example, source code, target code, compiled code, interpreted code, executable code, static code, dynamic code, or the like, and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language, e.g., C, C++, Java, BASIC, Pascal, Fortran, Cobol, assembly language, machine code, or the like.

Embodiments of the invention may include apparatuses for performing the operations herein. These apparatuses may be specially constructed for the desired purposes, or they may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROM), random access memories (RAM), electrically programmable read-only memories (EPROM), electrically erasable and programmable read only memories (EEPROM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions, and capable of being coupled to a computer system bus.

In the following description, various figures, diagrams, flowcharts, models, and descriptions are presented as different means to effectively convey and illustrate different embodiments of the invention that are proposed in this application. It shall be understood by those skilled in the art that they are provided merely as illustrative samples, and shall not be constructed as limiting.

FIG. 1is a block diagram illustration of a multi-sequencer system100according to one illustrative embodiment of the invention.

Multi-sequencer system100, as shown inFIG. 1, may include a memory102and a multi-sequencer hardware104. Memory102may include, for example, a user-level program106, a scheduler108, an Application Program Interface (API)110, and an Operating System (OS)112. Multi-sequencer hardware104may include, for example, a sequencer manager114, and a plurality of sequencers, for example, sequencers116,118,120and122, denoted as sequencers SID0, SID1, SID2, and SID3, respectively inFIG. 1. Although four sequencers are shown inFIG. 1, a person skilled in the art may appreciate that multi-sequencer hardware104may have other numbers of sequencers.

Sequencer manager114may be implemented as a driver, an extension of an operating system such as an extension of OS112, any other hardware or a combination of hardware and software. Multi-sequencer hardware104may be symmetric or asymmetric in terms of the types of sequencers116,118,120and/or122. One or more of the sequencers116,118,120and/or122may be a physical processor with its own set of execution resources. Alternatively, one or more of the sequencers116,118,120and/or122may be a logical processor (of, for example, a hyper-threaded processor), that may share physical resources with other logical processors. Sequencers116,118,120and122may be implemented in a single hardware core or in multiple separate hardware cores.

A non-exhaustive list of examples for multi-sequencer system100may include a desktop personal computer, a work station, a server computer, a laptop computer, a notebook computer, a hand-held computer, a personal digital assistant (PDA), a mobile telephone, a game console, and the like.

A non-exhaustive list of examples for memory102may include one or any combination of the following semiconductor devices, such as synchronous dynamic random access memory (SDRAM) devices, RAMBUS dynamic random access memory (RDRAM) devices, double data rate (DDR) memory devices, static random access memory (SRAM) devices, flash memory (FM) devices, electrically erasable programmable read only memory (EEPROM) devices, non-volatile random access memory (NVRAM) devices, universal serial bus (USB) removable memory devices, and the like; optical devices, such as compact disk read only memory (CD ROM), and the like; and magnetic devices, such as a hard disk, a floppy disk, a magnetic tape, and the like. Memory102may be fixed within or removable from system100

According to one illustrative embodiment of the invention, user-level program106may access a thread library via Application Program Interface (API)110. API110may provide creation, control, and synchronization of threads to user-level program106. Scheduler108may schedule instructions of the threads for execution on multi-sequencer hardware104.

A non-exhaustive list of examples for multi-sequencer hardware104may include a plurality of single-threaded or multi-threaded central processing unit (CPU), digital signal processor (DSP), reduced instruction set computer (RISC), complex instruction set computer (CISC) and the like. Moreover, multi-sequencer104may be part of an application specific integrated circuit (ASIC) or may be a part of an application specific standard product (ASSP).

According to one illustrative embodiment of the invention, multi-sequencer hardware104may be a single-core processor having implemented sequencers116,118,120and122(SID0-SID3) that may be, for example, logical processors. Single-core processor104may be able to support, for example, concurrent, simultaneous, and/or switch-on-event multi-threading. According to one illustrative embodiment, each of the sequencers SID0-SID3may have its own next-instruction-pointer logic, while the same single-core processor104may execute all the thread instructions. Each logical processor SID1-SID3may maintain its own version of the architecture state, although execution resources of single-core processor104may be shared among concurrent, simultaneous, and/or switch-on-event threads.

While the illustrative embodiment of multi-sequencer hardware104discussed above may refer to single thread per sequencer, a person skilled in the art shall appreciate that the application herein is not limited to single-threaded processors. The techniques discussed herein may equally be employed in any Chip Multiprocessing (CMP) or Simultaneous Multithreading Processor (SMP) system, including in a hybrid system with CMP processors and SMP processors where each core of a CMP processor is a SMP processor or a Switch-On-Event Multiprocessor (SoeMP). For example, the techniques disclosed herein may be used in a system that includes multi-threaded processing cores in a single chip hardware package104

As is discussed above, sequencers SID0-SID3are not necessarily uniform and may be asymmetric with respect to factors that may affect computation quality such as, for example, processing speed, processing capability, and power consumption. For example, sequencer SID0may be a “heavyweight” sequencer in that it may be designed to process most of the instructions in a given instruction set architecture (e.g. IA-32 Instruction Set Architecture associated with a 32-bit processor). Whereas, sequencer SID1may be a “lightweight” sequencer in that it may process a selected subset of those instructions. In another embodiment of the invention, a heavyweight processor may be one that processes instructions at a faster rate than a lightweight processor. In addition, some sequencers may be visible and other sequencers may be invisible to an operating system. For example, sequencer SID0may be visible to OS112, whereas sequencers SID1to SID3may be sequestered from OS112. However, this does not mean that heavyweight sequencers are OS-visible and/or lightweight sequencers are OS-sequestered. An operating system does not schedule instructions on a sequencer that is in a sequestered state (such a sequencer is referred to herein as an OS-sequestered sequencer).

According to some illustrative embodiments of the invention, multi-sequencer system100may be able to provide services of persistent user-level threads (PULTs), as detailed below with reference toFIGS. 2-8. In this application, a regular user-level thread, or simply referred to hereinafter as user-level thread, may be a sequence of instructions that contains only non-privileged instructions that run in a user-level or ring-3 level. Typically a user-level thread may be supported “behind the scenes” by an OS thread, which may also be denoted as native OS thread or just native thread. In this OS thread context, at least one user-level thread may run either on an OS-visible sequencer or an OS-sequestered sequencer. When the OS thread is context switched out (and in) by the OS, the contexts of all the sequencers belonging to the OS thread will be saved (and restored). Accordingly, the user-level threads running on these sequencers will be suspended (and resumed). According to one embodiment of the invention, a persistent user-level thread (PULT) is a user-level thread that runs on an OS-sequestered sequencer. The PULT may be executed in an environment, for example, a virtual address space (VAS) of another user-level thread that creates the PULT. The execution of the PULT may be independent of; and therefore not in synchronous with, the execution of the user-level thread that creates the PULT. Even when the OS thread to which the user-level thread belongs is context switched out, the PULT may continue execution on the OS-sequestered sequencer. This is referred to herein by the notion of “persistence”—continued execution of the user-level thread irrespective of the OS thread context switch activities on the thread that spawned or created the PULT.

FIG. 2is a simplified logical view of hardware200that forms a part of a multi-sequencer system according to one illustrative embodiment of the invention.

Hardware200may correspond to multi-sequencer hardware104that forms a part of multi-sequencer system100inFIG. 1. Multi-sequencer hardware104may include sequencer manager114and, for example, a plurality of sequencers116,118,120and122as shown inFIG. 1. According to one embodiment of the invention, sequencer manager114may be able to virtualize sequencers116,118,120and122in such a way that sequencers116,118,120and122appear to user-level program106as uniform and symmetric. In other words, sequencer manager201, which corresponds to sequencer manager114inFIG. 1, may mask the asymmetry of sequencers211,212,213and214so that from a logical point of view of an assembly language programmer sequencers211,212,213and214may look uniform and symmetric, as inFIG. 2, and symbolized by their squares of equal size. Sequencers211,212,213and214may represent logical processors SID0, SID1, SID2and SID3inFIG. 1.

FIG. 3is a simplified illustration of a multi-sequencer system300able to provide persistent user-level thread services according to one illustrative embodiment of the invention.

According to one embodiment of the invention, execution of an application301, which may be, for example, user-level program106ofFIG. 1may be managed by an operating system (OS)302. OS302may handle execution of application301by creating and scheduling one or more native threads, each potentially including user-level threads, such as for example a native thread303inFIG. 3which run on one of a set of sequencers that are visible to OS302, for example, sequencers311and312. OS302may manage sequencers311and312through one or more of its OS kernels. OS302may also control the privilege states of sequencers311and312and be responsible for handling interrupts and exceptions that may occur on sequencers311and312.

According to one embodiment of the invention, a sequencer manager310may have control access to both sequencers311and312that are OS-visible, and another set of sequencers, for example, sequencers313,314,315,316,317and318that are sequestered from OS302and not managed by the kernels of OS302. Sequencers313,314,315,316,317and318are OS-sequestered, or “OS-invisible”, sequencers.

According to one embodiment of the invention, an OS-scheduled thread, (e.g., a native thread that potentially includes a user-level thread) may interact with sequencer manager310through an interface that may be provided through hardware or software or a combination of both. In order to use sequencers that are not visible to OS302, such as sequencers313,314,315,316,317and318, an OS-scheduled thread, for example the native thread303, may send a request to sequencer manager310to create a user-level thread, for example, thread304, to run on one of the OS-sequestered sequencers, for example, sequencer313. According to one embodiment of the invention, user-level thread304may run on sequencer313independent of the OS context switch activities of the native thread303and therefore may be a persistent user-level thread (PULT).

In the following description, native thread303is used as an example to illustrate the creation and execution of a persistent user-level thread. A person skilled in the art will appreciate that following description also applies to other threads such as, for example a user level thread that belongs to a native thread.

According to one illustrative embodiment of the invention, OS-sequestered sequencer313may execute PULT304in a virtual address space (VAS)320that is shared by user-level thread303running on OS-visible sequencer3110S302may create VAS320for the execution of application301. According to one illustrative embodiment of the invention, by sharing a common VAS320, sequencer manager310may be able to capture an execution environment, for example, a virtual address map, of user-level thread303that runs on OS-visible sequencer311, and then apply this execution environment to PULT304that runs on OS-sequestered sequencer313. According to one embodiment of the invention, OS-sequestered sequencer313may have one or more snoopy TLB's (Translation Lookaside Buffer) that are able to automatically track future changes in the virtual address space. A TLB may be a small cache present in a processor that keeps track of virtual to physical address translation for quick lookup. A processor may use this TLB to avoid unnecessary page walks to translate virtual address to physical address.

FIG. 4is a conceptual illustration of a multi-sequencer system400able to provide persistent user-level thread services according to one illustrative embodiment of the invention.

According to one embodiment of the invention, multi-sequencer system400may include a sequencer manager410that manages a plurality of OS-sequestered sequencers, for example, sequencers411,412,413and414; and other OS-visible sequencers, for example, sequencers405and406. An operating system (OS)402may manage execution of one or more user-level applications, for example, applications401A and401B. OS402manages applications401A and401B by creating one or more threads including, for example, user-level threads403and404, which run on OS-visible sequencers405and406, and other native threads.

Sequencer manager410may provide execution resources to applications401A and401B through access to sequencers411,412,413and414, which are sequestered from OS402and not managed by OS402. The access may be provided through requests made by threads403and404running on OS-visible sequencers405and406or other native threads scheduled by the OS. As a result, applications401A and401B may have access to OS-sequestered sequencers411,412,413and414via user-level threads403and/or404or other native threads.

According to one embodiment of the invention, sequencer manager410may allocate various time slots on sequencers411,412,413and414for execution of one or more persistent user-level threads created by user-level threads403and404for applications401A and401B. For example, symbols t1, t2, t3, t4, t5and t6inFIG. 4may denote the time slots that are assigned for the execution of PULTs T1, T2, T3, T4, T5and T6, respectively.

According to one embodiment of the invention, sequencer manager410may set up one or more interrupt descriptor tables, for example, tables421,422,423and424, for one or more OS-sequestered sequencers, for example, sequencers411,412,413and414. An interrupt descriptor table, for example, table421, may include an event handler431to handle events occurring on sequencer411. During execution time, for example, t3of PULT T3on an OS-sequestered sequencer, for example, sequencer411, PULT T3may encounter an event or situation such as, for example, a page fault or a system call, that requires handling or attention of OS402. Event handler431may then suspend the execution of PULT T3and save the execution state, at the time the event happens, of PULT T3.

According to another embodiment of the invention, an OS-invisible sequencer, for example, sequencer411may directly interrupt the execution of an OS-visible sequencer, for example, sequencer405that invoked the PULT T3, when encountering a page fault or a system call. Sequencer411may then send a trigger to sequencer manager410requesting handling of the interruption. According to yet another embodiment of the invention, OS-sequestered sequencer411may program a ring-0 service channel or channel to handle a page fault or system call. A channel may be a register holding architectural state that includes, for example, a trigger-response mapping where the trigger is an architecturally defined set of one or more processor conditions and the response is a service routine. In addition, a channel may be programmed, for example, by a user-level instruction. When the page fault or system call occurs, OS-sequestered sequencer411may invoke a handler whose address is specified in the channel.

PULT T3may remain suspended until a time when a new user-level thread, for example, thread409, which runs the same application401A, is scheduled to run on an OS-visible sequencer. Thread409, also referred to as a service thread, may make a request to sequencer manager410to confirm or verify whether there are any PULTs that have been suspended and are waiting for OS services which may be provided, for example, through a proxy execution as described below in detail. A proxy execution may be performed through thread409impersonating or imitating PULT T3, by picking up the state of PULT T3from sequencer manager410. The execution state of PULT T3may be resumed by service thread409which shares a common address space, for example, a commonly shared virtual address space (VAS) (FIG. 3). Thread409may then service the execution condition that has caused the suspension of PULT T3. After the service, thread409may proceed to save the post-execution state and return the state to sequencer manager410. Sequencer manager410may subsequently pass the state to PULT T3to resume its execution.

The proxy execution discussed above may create an illusion of symmetry to an application programmer and therefore hide the inherent asymmetric nature of how a multi-sequencer system, for example, system100, is built.

FIG. 5is an illustrative view of an Instruction Set Architecture (ISA)500of a multi-sequencer system according to one illustrative embodiment of the invention.

An ISA defines a logical view of a system as seen by an assembly language programmer, binary translator, assembler, or the like. ISA500may include a logical storage502and an instruction set504. Logical storage502may define a visible memory hierarchy, addressing scheme, register set, etc for a multi-sequencer system such as, for example, multi-sequencer system100as inFIG. 1, whereas instruction set504may define the instructions and the format of the instructions that multi-sequencer system100may support.

Instruction set504may include the instruction set known as IA-32 instruction set and, according to illustrative embodiments of the invention, its extension although the present invention is not limited in this respect and other instruction sets are possible. According to one embodiment of the invention, instruction set504may include, for example, an E-SXFR instruction that includes a SXFR control-transfer instruction and its extension, and an E-SEMONITOR instruction that includes a SEMONITOR monitoring instruction and its extension. Compared to SXFR and SEMONITOR, which can be performed between two sequencers belonging to the same OS native thread, E-SXFR and E-SEMONITOR can be performed between two sequencers that belong to two distinct OS native threads respectively, which may run at different privilege levels. For example, one thread may be a user-level application that is subject to OS context switch, and the other thread may be a PULT that runs persistently in the privilege level, like a device driver, and is not subject to OS context switch.

According to one embodiments of the invention, the E-SXFR instruction may be used to send a signal from a first sequencer to a second sequencer, and the E-SEMONITOR instruction may be used to configure the second sequencer to monitor for signals coming from the first sequencer. Furthermore, the E-SXFR control transfer and E-MONITOR monitoring instructions are sequencer aware, and may be used to construct other sequencer aware composite instructions.

According to one embodiment of the invention, an E-SXFR instruction may have a sample instruction format as shown inFIG. 6. It is shown, inFIG. 6, that the E-SXFR instruction may include an Opcode602, and operands604,606,608,610and612. According to one embodiment of the invention, a sequencer manager may provide an E-SXFR instruction with operands, which may include the privilege state of a sequencer, such as to create an execution environment to service suspended persistent user-level threads.

According to one embodiment, operand604may correspond to a sequencer ID (SID) for a destination/target sequencer to which the E-SXFR instruction signal is sent. Operand606may include a scenario or control message, which may be an architecturally defined identifier code representing a condition or anticipated event. A scenario may be used to affect asynchronous control transfer as described in detail with reference to TABLE 1.

According to one embodiment, operand608may include a parameter that conditions the execution of instructions on a sequencer that executes the E-SXFR instruction. Examples of parameters, as shown inFIG. 6as conditional parameter, may include a “WAIT” or “NO-WAIT” parameter. For example, when an E-SXFR instruction is used in a proxy execution scenario, the WAIT conditional parameter may cause the execution of instructions on a sequencer that executes the E-SXFR instruction to stop, pending completion of proxy execution on another sequencer. The NO-WAIT conditional parameter may specify that execution on a sequencer that executes the E-SXFR. It instruction may continue in parallel with proxy execution on another instruction sequencer.

According to one embodiment, operand610may include a scenario-specific payload or data message. For example, in the case of a FORK scenario, the payload may include an instruction pointer at which execution on the sequencer identified by operand604is to commence. According to another embodiment, payload operand610may include an instruction pointer, a stack pointer, a set of control registers, etc. Addresses contained in payload operand610may be expressed in a variety of addressing modes such as, for example, literal, register indirect, and/or base/offset addressing.

According to one embodiment, operand612may specify a routing method or function on the SID contained in operand604. The routing function controls whether the signal, which is created as a result of executing the E-SXFR instruction, is sent as a broadcast, a unicast, or a multicast signal. The routing function may also encode information such as, for example, topology-specific hint that may be used to assist an underlying inter-sequencer interconnect in routing to deliver the signal.

According to one embodiment, the E-SEMONITOR instruction may have a sample instruction format as shown inFIG. 7. It is shown, inFIG. 7, that the E-SEMONITOR instruction may include an Opcode702, and operands704,706and708. Operands704,706and708may include information of the privilege state of sequencer to help create an execution environment for a persistent user-level thread. For example, operand704may specify a scenario by including a scenario ID. Operand706may include information related to a sequencer ID (SID) and an instruction pointer (EIP). For descriptive convenience, information contained in operand706may be referred to herein as a “SIDEIP”, as shown inFIG. 7

The E-SEMONITOR instruction may map a scenario specified in operand704to a SIDEIP specified in operand706. Mapping of a scenario to a SIDEIP may be referred to herein as mapping of a “service channel”. Operand708may allow a programmer to enter one or more control parameters to specify or control how a particular service channel is to be serviced. For example, a programmer may use the E-SEMONITOR instruction to program the service channels that a sequencer may monitor.

Based on the above description, it will be appreciated that both the E-SXFR and E-SEMONITOR instructions are “sequencer-aware” instructions in that they include operands that may identify particular sequencers.

FIGS. 8 and 9are simplified flowchart illustrations of the execution of a persistent user-level thread according to some illustrative embodiments of the invention. The same block numbers are used to indicate the same operation.

According to one embodiment of the invention, an OS-sequestered sequencer822may execute a persistent user-level thread as indicated at block801. The persistent user-level thread may be referred to herein as PULT-1 for convenience of description. PULT-1 may be created, for example, by a first user-level thread that is executed by a first OS-visible sequencer. During execution, PULT-1 may encounter one or more events that require services or attention of an OS. A second user-level thread, which may or may not be the same user-level thread as the first user-level thread that created PULT-1 and execute on a second OS-visible sequencer for example OS-visible sequencer821, may provide the requested OS services to PULT-1 as described below in detail.

According to one embodiment of the invention, PULT-1 may encounter an event at time t1requiring OS services, as indicated at block802inFIGS. 8 and 9. Upon detection of the event, a sequencer manager820may invoke a procedure to save the state of PULT-1 at time t1, as indicated at block803, such as a logic pointer, for example. The execution of PULT-1 may then be suspended from time t2and onward as indicated at block804, after the state of PLUT-1 has been saved as indicated at block803. According to one embodiment of the invention, the execution of PULT-1 may also be suspended by sequencer manager820, through an external interruption, after receiving a notification about an event that requires operating system services. PULT-1 may remain suspended until the requested OS services are provided through, for example, proxy execution by a service thread.

According to one illustrative embodiment of the invention, at some point of time, an OS-scheduled thread such as a new user-level thread may start to run on OS-visible sequencer821as indicated at block805. This new user-level thread may be executed for the same application as PULT-1 This thread may be able to provide OS services through, for example, proxy execution, to PULT-1 and therefore may be referred to herein as a service thread. Before providing OS services, the service thread may check or verify with sequencer manager820, as indicated at block806, whether there are any suspended PULTs that are waiting for OS services.

The service thread may identify PULT-1 as a thread waiting for OS services. According to one embodiment of the invention, the service thread may then proceed to imitate, in other words, impersonate, PULT-1 by picking up the execution state of PULT-1 through, for example, their commonly shared virtual address space (VAS) as indicated at block807. PULT-1, imitated by the service thread, may then get executed on the OS-visible sequencer executing the service thread to receive OS services. As a result, OS services are provided to PULT-1, as indicated at block808, through proxy execution of the service thread and the condition under which PULT-1 was suspended is now serviced by the operating system. According to one embodiment of the invention, a user level thread that runs on an OS-visible sequencer, for example, OS-visible sequencer821, may detect a suspended PULT by monitoring an address location using an scenario. A service scenario is a condition that may be used to monitor, for example, cache misses, and if a cache miss occurs which causes, for example, a threshold being crossed, a handler in the service channel may be invoked.

According to one embodiment of the invention, after the operating system completes servicing the condition of the suspended PULT-1, the post-execution state of PULT-1 may be saved and subsequently returned to OS-sequestered sequencer822through sequencer manager820as indicated at block809. After receiving the post execution state from the service thread, OS-sequestered sequencer822may resume its execution of PULT-1 as indicated at block810

Table 1 contains a list of sample scenarios according to some illustrative embodiments of the invention

According to illustrative embodiments of the invention, scenarios in Table 1 may be divided into egress services and ingress services. Among each service, operations and control messages may be characterized by their OS-visibility which may be part of the characteristics of a shred processing unit (SPU). Among egress services, there are scenarios of operations that fall into the category of resource not available (RNA), which is a category for events generated during execution on a sequencer due to access to a resource not being available on an OS-sequestered sequencer. According to one embodiment of the invention, scenarios that fall into the category of RNA may include, for example, page fault handling and/or I/O access on the OS-sequestered sequencer which is incapable of directly activating OS service.

According to illustrative embodiments of the invention, accompanying these scenarios of operations described above is a set of outgoing control messages. In one illustrative embodiment, the messages may include, for example, the messages as listed under egress service scenarios in Table 1. However, the invention is not limited in this respect and other messages may be used. The control messages go to one or more OS-visible sequencers.

In relation to the egress service scenarios discussed above, there are ingress service scenarios that fall into the category of an OS-visible sequencer providing resource to service requests from an OS-sequestered sequencer. As is shown in Table 1 under ingress service scenarios, these services correspond directly to the scenarios under egress service but are available from OS-visible sequencers. In one illustrative embodiment, the incoming control messages, accompanying the ingress services, may include the messages as listed under ingress service scenarios in Table 1. However, the invention is not limited in this respect and other messages may be used. The incoming messages may come from one or more OS-sequestered sequencers.

According to illustrative embodiments of the invention, instructions that serve the egress services are, for example, relatively simple SSE13 instructions in terms of core complexity, and instructions that serve, for example, the ingress services or requests from an OS-sequestered sequencer, are, in general, more complex.