WO2014011084A1 - Способ управления ресурсами в вычислительной системе - Google Patents

Способ управления ресурсами в вычислительной системе Download PDF

Info

Publication number
WO2014011084A1
WO2014011084A1 PCT/RU2013/000575 RU2013000575W WO2014011084A1 WO 2014011084 A1 WO2014011084 A1 WO 2014011084A1 RU 2013000575 W RU2013000575 W RU 2013000575W WO 2014011084 A1 WO2014011084 A1 WO 2014011084A1
Authority
WO
WIPO (PCT)
Prior art keywords
specified
distributed
resources
call stack
stack
Prior art date
Application number
PCT/RU2013/000575
Other languages
English (en)
French (fr)
Inventor
Александр Яковлевич БОГДАНОВ
Original Assignee
Bogdanov Alexander Yakovlevich
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 Bogdanov Alexander Yakovlevich filed Critical Bogdanov Alexander Yakovlevich
Publication of WO2014011084A1 publication Critical patent/WO2014011084A1/ru

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/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the invention defines methods for managing resources allocated for executing programs in local, multiprocessor, and distributed computing systems.
  • the resources can be random access memory, files, input / output devices, application objects, user interface objects, system objects, operating system objects, external devices.
  • application objects can be random access memory, files, input / output devices, application objects, user interface objects, system objects, operating system objects, external devices.
  • resource management includes the allocation of resources, the release of resources and access to resources.
  • resources used in the description means any resources, including RAM, files, input / output devices, application objects, user interface objects, system objects, operating system objects, external devices, etc.
  • resource and object are considered as synonyms.
  • the methods for allocating resources are usually obvious and depend on the type of resource, the functional purpose of the resource, the type of executive system, programming language, architecture of a particular system, or other factors. Ways to automatically free resources after they become unnecessary for an application are more complex.
  • stack memory is widely used to manage the resources of a program that runs locally (not in a distributed environment). Using the stack is a simple and extremely efficient way to allocate and free resources. First, the memory is allocated and freed sequentially in a pre-allocated block of a sufficiently large size. Secondly, memory is freed up automatically and does not require any coding at the source code level of the program. In this case, the stack memory is automatically freed up both during normal program execution and when exceptional situations arise (that is, always).
  • the stack memory is used to allocate objects that are available locally for one program control flow.
  • the memory management algorithm in the stack imposes a certain restriction on its use, any program can be implemented using only the stack memory.
  • resource is a resource that is explicitly allocated in the program. Such resources can be used simultaneously in several places of the program, or shared by several control flows, or by several applications. For automatic management of dynamic resources not from the stack, resource reference counters, or linked resource reference lists, or garbage collectors are used. A resource is automatically freed when there are no relevant links in the program.
  • a possible solution to the problem of resource management in a distributed system is the transfer of stack-based memory management logic to a distributed environment. To some extent this is done in distributed memory with basic addressing, proposed in patent application WO2012 / 047134, System and method of distributed computing, A. Bogdanov, 04/12/2012, p. 1-3, p. 8, FIG. 4.
  • This method is based on a remote procedure call and considers addressing in a distributed call stack.
  • Each node when receiving control in a distributed call stack, allocates memory blocks and sequentially adds them to the set of memory allocated in this distributed call stack. The total size of the memory allocated in the call stack is transferred to the next remote procedure call instruction. All memory allocated in the call stack is considered as continuous.
  • the memory address is calculated as the offset from the beginning of the first allocated block. If, when accessing the specified distributed memory, the node determines that it is not in its memory, it refers to the previous node by a chain of calls in the distributed stack.
  • the addressing method proposed in said application has disadvantages. Firstly, it uses only blocks of RAM as a resource. Secondly, addressing using absolute offset limits the use of this method in programming languages that do not support direct work with addresses. Thirdly, this method has limited resources for freeing resources (resources can be released only when control returns in a distributed stack). Fourth, it does not determine the mechanisms of interaction between nodes if the system simultaneously executes many distributed control flows. Fifthly, it does not provide for the simultaneous use of resources by several distributed flows. Sixth, it does not provide for the use of static resources (in particular, static memory). Disclosure of invention
  • the claimed invention contemplates resource management in a local and / or distributed system.
  • the systems in question include one or more an executive element that has a memory for storing programs and data.
  • the executive element executes the program instructions that are located in its memory.
  • Each actuator may have its own memory, or any subset of actuators may have a common memory.
  • the presence of only one actuating element is considered as a particular version of the system in which individual elements are not included simultaneously.
  • the program created on the basis of the invention remains operational when one or a plurality of actuating elements are operated.
  • the executive elements can be in any combination of a kernel in a multicore system or processors in a multiprocessor system or computer processors connected through a network, or software-implemented virtual systems or process instances of a real or virtual system that execute an application in their address space in one or different executive systems.
  • the method works the same way as with the local interaction of programs that run on the same computer in one executive system, and when interacting in a multiprocessor, network or other distributed environment in an arbitrary combination.
  • Actuators can interact with each other. Connections of actuating elements each with each is optional.
  • the invention supports chains of connections through intermediate nodes of any length.
  • the invention When used in a local system, the invention is intended for local interaction between instances of programs that run in their isolated address spaces, or have independent resource management. Another possible application of the invention is the resource management of a program that runs on multiple actuators.
  • new resources may be allocated or previously allocated resources may be provided for use. In both cases, resources can be considered as provided.
  • Resources provided in any way can only be used by a specific distributed stack. calls, or resources can be used by more than one distributed stack. Resources can be dynamic or static.
  • the interaction between the actuators is based on the control transfer instruction, which allows you to transfer the control flow from one actuator to another. In a typical implementation, this is a remote or local procedure call.
  • the control transfer instruction considered in the invention can transfer control both from one actuating element to another, and within the boundaries of one actuating element.
  • the mechanism for implementing a remote or local procedure call is not significant for the invention. It can be means of interprocess communication using a parallel bus, or it can be interaction based on shared memory, or it can be messaging based on a serial or parallel bus or network environment. Methods for finding and identifying remote or local procedures are also not essential to the invention.
  • the invention is based on resource management using a stack, which is transferred to a distributed environment.
  • a stack In the classical organization of the computing process, short-lived objects are stacked. Objects are created in the frame of the procedure stack and destroyed when control returns from the procedure.
  • the present invention proposes to use the reverse instruction to control the lifetime of an object.
  • the main feature of the reverse instruction is that it does not return control from the transfer control instruction and does not unwind the distributed stack.
  • the reverse instruction allows you to save stack objects for any time and automatically delete them when control is returned from the original control transfer instruction.
  • Typical examples of the reverse instruction can be a remote or local call to a procedure that accesses a resource, and remote memory access operations (reading / writing data or memory attributes).
  • the return instruction is a control transfer instruction, it may or may not continue the distributed call stack.
  • the parameters of such a reverse instruction may contain links to resources allocated on any node for this distributed call stack. The following can be used to access these resources. reverse instruction.
  • a procedure call is a special case of a control transfer instruction.
  • the proposed method of resource management is:
  • each distributed call stack has its own resource space, and each node in the distributed call stack manages its resources.
  • the claimed method can be used both in peer-to-peer systems and in client-server systems.
  • Another technical result of the considered resource management method is the ability to remotely access memory elements in the event that the executive system or programming language does not provide direct use of relative addressing.
  • these can be interpreted programming languages, for example, JavaScript.
  • the claimed invention allows as a remote reference to use the numerical index of an element in memory or a key value or associative address (for example, the name of a variable or function in the program code).
  • Another technical result is the ability to associate a distributed call stack with network connections. This allows directly Use network services for unreliable data delivery without a connection. Another advantage is the ability to organize chains of network connections. In particular, this allows guaranteed release of resources while silently completing any subset of connections in the chain.
  • the claimed invention eliminates all of the above disadvantages of the prototype without losing the existing technical effect.
  • FIG. 1 is a diagram illustrating the claimed invention.
  • two actuators interact with the conventional names Node A and Node B.
  • An instruction with the conditional name Bind determines the moment when the distributed call stack starts executing on Node A. Starting from this moment, in the interval 10, Node A can allocate resources that will be available in this distributed stack. For example, in this interval, OBJECT1 is created, which is an object in memory with a remotely called function.
  • Instruction 11 (with the code name SCALL) transfers control to Node B.
  • the SCALL instruction may include information about resources allocated in the distributed stack. Such information may be attached to the remote call message and / or the procedure call parameters may include explicit links to the provided resources (in FIG. 1, an OBJECT pointer).
  • Block 14.1 illustrates resources for which pointers are calculated independently of other resources (the implementation of possible types of pointers is discussed below). Such resources can be attached to resources that are allocated in interval 10.
  • Block 14.2 illustrates the resources that should be released when control is returned from instruction 13.
  • Instructions 15 return control from instruction 13. If resources were allocated in interval 14.2, they are exempted. In the interval 16 are available resources allocated in intervals 10, 12 and 14.1. References to resources 14.1 can be passed as a return value in instruction 15.
  • Instruction 17 returns control from instruction 11. If resources were allocated in intervals 12 and 16, they are freed.
  • Node A shows two instructions 11 and 19 that make an initial call in a distributed call stack.
  • the distributed stack does not have an executable initial instruction for distributed control transfer.
  • a call to Node A may allocate new resources that will be added to resources 10 and 14.1.
  • Statement 19 (SCALL) makes another distributed call.
  • Node A initiates the creation of a distributed stack. To complete the execution of the distributed stack on this node, an instruction with the code name untie is used. At the same time, resources allocated in the intervals 10, 14.1, 18 and 111 (including OBJECT1) are freed.
  • Another option for shutting down a distributed call stack on a node is to return control from the first control transfer instruction through which that node received control.
  • This embodiment is shown in FIG. 1, if the LINK instruction is replaced by SCALL, and the LINK instruction is RETURNED (resources 12 and 16 are freed in the same way when instruction 17 is executed).
  • FIG. Figure 1 shows one distributed call stack with a maximum call depth of stack 2. Only two actuators are involved in the interaction. These restrictions are presented for ease of presentation only. In the general case, any number of actuating elements can interact, one or more distributed call stacks can be executed simultaneously in the system, and the depth of each distributed call stack can be any (the depth of the distributed call stack can be limited by a reasonable value in order to avoid looping and unlimited long call chains )
  • the diagram below can be considered as a fragment of a distributed call stack that has any call depth at the time of receiving Node A. control this, in all the considered intervals, the resources provided to this distributed call stack at the time of receiving the control of Node A will be available.
  • resources on a node can be provided at intervals in which this node receives control in a given distributed call stack. Due to this, the provision of resources is performed locally and does not require special control traffic between system nodes.
  • the provided resource of the actuating element releases or modifies the control information upon returning control from this actuating element in the distributed control transfer instruction, or the provided resource of the actuating element releases or modifies the control information when the distributed call stack is completed on this actuator.
  • the release of the resource occurs locally and does not require the transfer of special information between the nodes of the system.
  • all resources that were provided for the distributed call stack on the executive element are freed.
  • the provided resource of the executive element releases or modifies control information when executing a program instruction that explicitly releases this resource (not shown in Fig. 1). For example, a resource may be explicitly released if that resource is no longer needed in the program.
  • the resource provided may belong to a specific call stack, or the resource may be shared by different call stacks. If each resource in the system belongs to only one distributed call stack, block-free programming can be implemented. To access a shared resource, a copy of this resource (either a gateway or a bridge) can be created. The interaction between a copy of a shared resource and the resource itself can be based on local asynchronous message passing.
  • the release of resources can be considered as a modification of control information when releasing any type of provided resources. For example, freeing memory on the local stack is done by changing the value in the stack register, and freeing memory from the heap is done by modifying control tables. To free resources that are used by several distributed stacks, control information is modified in the reference counter or in the linked list of links. The real release of the resource occurs after the resource is freed by all distributed stacks on the actuator. If local garbage collectors are used, the actual release of the resource may be delayed.
  • the resources of the executive element are provided to the program, if necessary.
  • An arbitrary subset of actuators in a distributed call stack may not provide resources if they are not needed. If no resources are allocated on the executive element and it does not need to process control returns in the distributed call stack, the executive element can exclude itself from the distributed stack. In that In the event, he must transmit to the next executive element information about the executive element from which he received control. In addition, he must transmit to the previous executive element information about the next executive element. If there is no previous actuator (the current actuator is the initial one), then a message may be sent, meaning that control is not required.
  • a feature of this method of resource management is the guaranteed release of resources at the end of the distributed call stack.
  • a distributed stack can be completed in the following ways: ⁇ End back. This method is performed when the control returns normally from the control transfer instruction or when control returns through an exception. Upon completion of the entire call stack, the distributed stack sequentially spins back with the release of resources executive elements in the call chain.
  • ⁇ Completion forward This method is used if the initiator of termination is an executive element that is currently not located at the top of the distributed call stack. In this case, the stack does not spin up, but a special message is sent to complete the stack. This message is sequentially transmitted through the call chain from the initiator of completion to the executive element at the top of the distributed call stack (if possible). Each actuator, upon receipt of a distributed stack completion message, must release the resources that are provided to this stack.
  • Distributed stack execution can be completed by any node in the call chain. If the termination initiator is not at the ends of the distributed call stack chain, the forward and reverse termination is performed at the same time. Completion back can be done by raising an exception. The completion methods under consideration make it possible to reliably release the resources of the distributed stack while simultaneously disabling an arbitrary subset of nodes in the call chain.
  • Another technical result of the use of the claimed invention is a consistent global state of the stack when interacting independently developed programs.
  • each program is actually an independent state machine with its own set of state variables and its own transition logic.
  • RPC / LPC calls are implemented as loosely coupled messaging-based communications.
  • the global state of the system and the global logic of work are difficult to predict. This increases development complexity and reduces reliability.
  • the resources provided in the stack can be considered as state variables. Typically, references to these resources are passed between the actuators as call parameters and return values of the RPC / LPC procedures.
  • the resources that determine the state of the distributed call stack are known and are part of the interaction protocol.
  • the resources of a distributed stack can be logically isolated from the state variables of individual programs.
  • Distributed stack state variables can determine both the global state of the entire stack and the state of individual connections or a separate subset of connection chains.
  • the state change is performed through the reverse instruction and is an integral part of the interaction protocol. In particular, this makes it easy to develop distributed applications whose logic is based on the state of connections between multiple nodes.
  • Another option is to use the invention in the interaction of programs with poorly managed state, for example, Web - pages.
  • FIG. 1 A diagram that illustrates the invention.
  • FIG. 2. Scheme for implementing the system in accordance with the invention.
  • FIG. 2 shows a diagram of a possible implementation of the claimed invention.
  • C ++ It can be different programs or a copy of one program.
  • Programs are developed using the C ++ template library um.h - 23, 24.
  • This library is based on the claimed invention. It includes a set of templates, which are an extension of the language and allow you to hide the details of distributed interaction at the source code level of the program.
  • the templates from the um.h library interact with the system service 25, 26.
  • the system service implements the logic of the present invention.
  • Programs are executed on executive elements - computers with the conventional names NODE A, NODE B and NODES N-N. Computers are connected through a network 27. The implementation under consideration allows programs running on one or different computers to interact in any combination.
  • System Service 25, 26 is an extension of the operating system. It implements its own remote and local procedure call protocol (RPC and LPC) in accordance with the present invention.
  • RPC and LPC remote and local procedure call protocol
  • a specific implementation of RPC and LPC is not essential to the invention.
  • RPC and LPC are well-known software interoperability technologies that have many private and standardized implementations.
  • the organization of the computing process in the system under consideration includes two types of program control flows. These are local control flows and distributed control flows.
  • the distributed control flow is determined by the RPC / LPC call chain and runs in the context of a distributed call stack. When a distributed control flow is executed on a specific actuator, it is executed by some local control flow.
  • the following options for implementing communication between local and distributed control flows are possible:
  • a distributed stream is associated with a specific local stream. With this connection, the distributed flow is a chain of certain local streams. RPC / LPC calls are made synchronously. The local thread is freed when it returns control from a distributed call. This method is simple and well suited for peer-to-peer and client systems. The disadvantage of this method is poor scaling in server systems that simultaneously process a large number of requests. • A distributed thread runs on a specific node in the context of some local control flow. If the distributed control flow pauses or makes an RPC / LPC call, the released local control flow may execute another distributed control flow. This method supports asynchronous calls and scales well in server systems.
  • a special control structure is created in the computer memory to control the distributed call stack on the local computer.
  • This structure includes the unique identifier of the distributed call stack, the address of the previous and next node in the distributed call stack, links to resources allocated on the node for this stack, information about the network connections used and other information.
  • This control structure either explicitly or implicitly, is involved in operations with a distributed call stack.
  • Node B runs a program with the following source code:
  • Lines 1, 17 include the um.h template library described above.
  • Lines 2-6 define the object to be created as a resource for the callback.
  • Line 7 defines a function - a stub for a remote call, which is used as a prototype when forming a remote call.
  • Lines 9, 10 and 25, 26 record the procedures for remote calls.
  • the InitDStack () function initializes the distributed stack. This creates a UMDS structure that will control the execution of the distributed stack on Node A.
  • B line 12 the BindDStack () function associates the initialized distributed stack with the current local program control flow.
  • the BindDStack () function writes a pointer to the UMDS structure in a special variable, which is located in a certain place in the local memory of the stream.
  • a special variable which is located in a certain place in the local memory of the stream.
  • other methods of communicating the local and distributed control flow may be used.
  • an object of type Object1 which is a provided resource, is created in dynamic memory.
  • the index of this object in the memory allocated for the current distributed stack is written to a special distributed uptro pointer.
  • This type of pointer is implemented as a template in the um.h library.
  • the types of pointers used to address the memory of a distributed call stack are described below.
  • a reference to the provided object is associated with the UMDS control structure for subsequent automatic release of resources.
  • Line 14 contains a remote call to the runHello () function on Node B. This call is the start of the ds stack. In this call, a distributed pointer to an Objectl object is passed.
  • the RunDStack () function passes the local control flow to main () to process incoming RPC / LPC calls.
  • a distributed stack control structure is created on Node B. This structure is initialized with the values from the incoming RPC / LPC request.
  • the runHello () function is executed in the context of the received distributed stack.
  • Line 22 contains the return statement, which remotely calls the functHello () method of the Objectl object on Node A.
  • the flow of the main () function on Node A is idle and makes an incoming RPC call to the functHello () method. After that, control returns to Node B. Then the runHello () function finishes execution and control returns to Node A.
  • the UnbindDStack () function terminates the execution of the distributed call stack. In this case, the created Objectl object is automatically deleted.
  • This example program contains synchronous remote procedure calls, which are simpler to illustrate.
  • remote procedure calls can be synchronous or asynchronous.
  • Possible an asynchronous call implementation option may include a special function, a link to which is passed in the original remote procedure call. Calling back this function means returning control in the corresponding remote call instruction.
  • This function may have a parameter that matches the return value of the called procedure.
  • An object signaling an exceptional situation may act as another parameter.
  • An asynchronous call may or may not continue a distributed call stack.
  • resource information can be transmitted:
  • Distributed pointers can be used to address resources.
  • a possible option for addressing resources is a method in which resources that are provided in a distributed stack are sequentially added to the totality of resources provided in this distributed stack. The entire set of resources provided to the stack is considered as a single space.
  • the offset from the beginning of the memory allocated in the distributed call stack can be used as the distributed address of the resource (as proposed in the prototype).
  • a more universal way, which is proposed in the claimed invention, is the use of a numerical index of the resource.
  • Each resource allocated in the distributed stack is assigned a sequential numerical index.
  • the current maximum index of resources allocated in the distributed stack is passed to control transfer instructions.
  • Using an index as a distributed pointer allows, firstly, to address resources that occupy different lengths of memory, and secondly, not only memory can be used as resources (for example, descriptors of system objects or other software or hardware objects).
  • an index or a distributed address is associated with a local resource identifier based on a control table (or a control linked list).
  • Each executive element has its own part of the table for its resources of a certain distributed call stack.
  • a row in the table associates a distributed address or index with the local memory address of this resource (or another local resource identifier). If the application code accesses the resource, the executive element searches for this resource in the control table at its distributed address or index. If he does not find the resource in his control table, he refers to the previous executive element in the distributed call stack. If the resource belongs to a previous executive element, this executive element refers to the resource. Otherwise, the previous actuator accesses its previous actuator in the call stack.
  • indexes of a different type for example, string.
  • Such an index is not necessarily unique.
  • the algorithm for finding resources on a specific actuator is not essential for the invention. For example, an algorithm may be determined by the logic of the scope of variables. If the executive element does not find the resource in its memory, it refers to the previous executive element in the call stack.
  • a resource search is conducted in the aggregate allocated to the distributed memory stack, based on the associative address.
  • a resource can be the memory in which the code or a piece of program code, or dynamic data, or other resources is located. Indicated the above control tables are not required in this case.
  • the search sequence on a separate executive element is determined by the type of associative addressing. For example, if the resource is a procedure or a variable in memory, the search can be carried out by name in accordance with the rules for the visibility of names of a programming language. A program procedure can be considered as a static resource. If the executive element does not find the resource in its memory, it refers to the previous executive element in the call grid.
  • a string index or associative address allows you to associate a resource with its identifier during the development or setup phase of a program.
  • the resource identifier can be defined in the protocol of interaction of the actuating elements. The exchange of information between the executive elements to use such a resource is not required.
  • memory does not matter for the control tables described above.
  • memory of any type is located in one local address space. This can be memory from the local stack of the local control flow (with which the distributed call stack is associated), dynamic memory from the heap, or static memory. The type of memory provided determines how it should be freed.
  • Memory from the local stack is automatically deleted when the distributed call stack is spun.
  • Dynamic memory can be used simultaneously by several distributed call stacks.
  • local link counters local linked link lists, or local garbage collectors can be used.
  • the resource links themselves must belong to certain distributed call stacks.
  • a distributed reference to the same resource in different distributed stacks may have different values of the distributed address.
  • the link may include a pointer to the control structure of its distributed stack, or the link may include the identifier of the distributed stack. Links are deleted when the distributed stack on this actuator terminates. At the same time, control information is modified, which may be link counts or linked lists. If all the distributed call stacks that use the resource terminate on the executive element, then the used dynamic memory is automatically freed. At the same time, link management is completely local and does not require the transfer of messages between system nodes.
  • Static resources can be provided for use in distributed stacks and can never actually be freed.
  • a special pointer which includes the address of the actuator and a local resource identifier (for example, a local memory address).
  • the address of the Executive element can be used the network address of the node, or the processor number, or a combination of the process identifier and the address of the Executive element, or a virtual address, or something else.
  • Each such index contains complete information about the resource and does not depend on other resources provided (that is, the resources provided do not need to be considered as a single aggregate).
  • the control tables described above are not required.
  • the control transfer instruction does not need to transmit special control information.
  • One actuator can access the resource of another actuator through the network address of the actuator, which is contained in a distributed pointer.
  • Such pointers can simply be passed in parameters or in the return values of distributed procedure calls.
  • the claimed invention proposes to identify each running distributed stack using a unique identifier.
  • This identifier is unique in the computing system for the duration of the distributed call stack. It must be transmitted in distributed control transfer instructions (for example, as part of the control information). Missing identifier may treated as NULL - a value that can be assigned to a single distributed call stack. In particular, NULL - a value can be used in a system in which only one distributed call stack is executed.
  • GUID globally unique identifier
  • identifier is a digital signature of known information and / or information transmitted simultaneously with a unique identifier.
  • a digital signature as an identifier can be transmitted in full or in truncated form (to reduce the amount of traffic).
  • the technical result of using a digital signature is the ability to identify the computer or user who initiated the execution of the distributed call stack. It is also possible to embed digital signatures in a distributed stack call chain.
  • the unique identifier of the distributed stack allows us to consider the stack as a half-duplex connection that connects any number of nodes in the system.
  • the node that is currently in control is active. It can call another node's procedure or return control from a distributed control transfer instruction.
  • the remaining nodes of the call stack are passive. A passive node can become active when control returns from an executing control transfer instruction or when an incoming distributed procedure call is received.
  • two counter distributed call stacks with shared resources can be installed.
  • the claimed method is operational without a unique identifier for a distributed call stack.
  • the Executive element stores information about the previous Executive element in the call stack. Feedback the instruction can be passed back along the chain of calls to the executive element of the resource owner. Stack identification between each pair of nodes in the call chain is sufficient. If the system supports end-to-end identification of connection chains between actuators, a distributed stack can be associated with a specific connection. In this case, a separate distributed stack identifier is also not required.
  • a typical interaction in a client - server system in accordance with the claimed invention includes the following steps:
  • the client allocates a resource (object or function) for the callback and remotely calls the server procedure.
  • the server provides the resource necessary for the client and passes a link to it in the callback.
  • the claimed method is universal and can be used to solve many different problems.
  • the considered implementation of the invention is far from the only possible one. maybe many other implementations in various executive systems and in various implementations of remote and local procedure calls. It is safe to say that any implementation of RPC and LPC can be expanded in accordance with the claimed invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Multi Processors (AREA)

Abstract

Изобретение определяет способы управления ресурсами, выделяемыми для исполнения программ в локальных, многопроцессорных и распределенных вычислительных системах в любой комбинации. В качестве ресурсов может быть оперативная память, файлы, устройства ввода/вывода, прикладные объекты, объекты пользовательского интерфейса, системные объекты, объекты операционной системы, внешние устройства. Предлагаемый способ основан на логике управления стековой памяти, которая перенесена в распределенную среду. Основным техническим результатом является простое, надежное, эффективное, децентрализованное и универсальное автоматическое управление ресурсами в распределенной вычислительной системе, которое не требует специального обмена сообщениями между узлами системы.

Description

Способ управления ресурсами в вычислительной системе Описание изобретения
Область техники, к которой относится изобретение
Изобретение определяет способы управления ресурсами, выделяемыми для исполнения программ в локальных, многопроцессорных и распределенных вычислительных системах. В качестве ресурсов может быть оперативная память, файлы, устройства ввода/вывода, прикладные объекты, объекты пользовательского интерфейса, системные объекты, объекты операционной системы, внешние устройства. Уровень техники
Рассматриваемое в заявляемом изобретении управление ресурсами включает выделение ресурсов, освобождение ресурсов и доступ к ресурсам. Использованный в описании термин «ресурсы» подразумевает любые ресурсы, в том числе оперативную память, файлы, устройства ввода/вывода, прикладные объекты, объекты пользовательского интерфейса, системные объекты, объекты операционной системы, внешние устройства и прочее. В контексте настоящего описания термины ресурс и объект рассматриваются как синонимы.
Способы выделения ресурсов обычно являются очевидными и зависят от типа ресурса, функционального назначения ресурса, типа исполнительной системы, языка программирования, архитектуры конкретной системы или других факторов. Способы автоматического освобождения ресурсов после того, как они становятся не нужными приложению, являются более сложными.
В большинстве случаев выделение и освобождение ресурсов тесно связано с операциями выделения/освобождения памяти или модификацией управляющей информации в памяти. В настоящее время для управления ресурсами программы, которая выполняется локально (не в распределенной среде), широко используется стековая память. Использование стека является простым и чрезвычайно эффективным способом выделения и освобождения ресурсов. Во-первых, память выделяется и освобождается последовательно в заранее выделенном блоке достаточно большого размера. Во-вторых, освобождение памяти происходит автоматически и не требует какого-либо кодирования на уровне исходного текста программы. При этом стековая память автоматически освобождается как при нормальном выполнении программы, так и при возникновении исключительных ситуаций (то есть, всегда).
В типичном случае стековая память используется для выделения объектов, которые доступны локально для одного потока управления программы. Хотя алгоритм управления памятью в стеке накладывает определенное ограничение на ее использование, любая программа может быть реализована с использованием только стековой памяти.
Другим типом ресурсов являются ресурсы, которые выделяются в программе явным образом. Такие ресурсы могут использоваться одновременно в нескольких местах программы, или совместно несколькими потоками управления, или несколькими приложениями. Для автоматического управления динамическими ресурсами не из стека используют счетчики ссылок на ресурс, или связанные списки ссылок на ресурс, или сборщики мусора. Ресурс автоматически освобождается, когда на него нет актуальных ссылок в программе.
Рассматривая управление ресурсами в распределенной среде, ,в настоящее время в основном используются счетчики ссылок. Реализация счетчика ссылок при локальном исполнении приложения достаточно проста и надежна. В то же время, перенос счетчика ссылок в распределенную среду является сложной задачей, не имеющей точного решения. Во-первых, это связано с тем, что не всегда имеется возможность полностью согласовать алгоритмы управления на разных узлах системы. Во-вторых, в распределенной системе любой узел или приложение может в любой момент аварийно отключиться без посылки сообщения. Для решения этой проблемы узлы, которые выделяют ресурсы, должны удерживать прямые соединения с каждым узлом, который использует ресурс. Эти соединения должны постоянно тестироваться. Однако, при сложной конфигурации сети или многопроцессорной системы установление прямых соединений не всегда возможно. Цепочки независимых соединений не всегда позволяют вычислить аварийное отключение пользователя ресурсов. Это приводит к ошибочному зависанию ресурсов. В-третьих, управление ресурсами требуется отдельно для каждого ресурса и для каждой ссылки на ресурс. Такое управление требует передачу сообщений между узлами системы для каждого ресурса. Это создает существенный управляющий трафик в распределенной среде и замедляет выполнение программы.
Возможным вариантом решения проблемы управления ресурсами в распределенной системе является перенос логики управления памятью на основе стека в распределенную среду. В некоторой степени это сделано в распределенной памяти с базовой адресацией, предложенной в заявке на патент WO2012/047134, Система и способ распределенных вычислений, Богданов А. Я., 12.04.2012, п. 1 - 3 формулы, стр. 8, фиг. 4. Данный способ основан на удаленном вызове процедуры и рассматривает адресацию в распределенном стеке вызовов. Каждый узел при получении управления в распределенном стеке вызовов выделяет блоки памяти и последовательно добавляет их к совокупности памяти, выделенной в этом распределенном стеке вызовов. Общий размер выделенной в стеке вызовов памяти передается в очередной инструкции удаленного вызова процедуры. Вся выделенная в стеке вызовов память рассматривается как непрерывная. Адрес памяти рассчитывается как смещение от начала первого выделенного блока. Если при обращении к указанной распределенной памяти узел определяет, что она находится не в его памяти, он обращается к предыдущему узлу по цепочке вызовов в распределенном стеке.
Предложенный в указанной заявке способ адресации имеет недостатки. Во- первых, в нем в качестве ресурса используются только блоки оперативной памяти. Во- вторых, адресация с использованием абсолютного смещения ограничивает использование этого способа в языках программирования, не поддерживающих прямую работу с адресами. В-третьих, указанный способ имеет ограниченные возможности по освобождении ресурсов (ресурсы могут быть освобождены только при возврате управления в распределенном стеке). В-четвертых, он не определяет механизмов взаимодействия между узлами, если в системе одновременно выполняется множество распределенных потоков управления. В-пятых, он не предусматривает одновременное использование ресурсов несколькими распределенными потоками. В-шестых, он не предусматривает использование статических ресурсов (в частности, статический памяти). Раскрытие изобретения
Заявляемое изобретение рассматривает управление ресурсами в локальной и/или распределенной системе. Рассматриваемые системы включают один или более исполнительный элемент, который имеет память для хранения программ и данных. Исполнительный элемент выполняет инструкции программы, которые расположены в его памяти. Каждый исполнительный элемент может иметь свою память, или любое подмножество исполнительных элементов может иметь общую память. Наличие только одного исполнительного элемента рассматривается как частный вариант системы, в которой отдельные элементы включаются не одновременно. При этом программа, созданная на основе изобретения, сохраняет работоспособность при работе одного или множества исполнительных элементов.
Исполнительными элементами могут быть в любой комбинации ядра в многоядерной системе или процессоры в многопроцессорной системе или процессоры компьютеров, соединенные через сеть, или реализованные программно виртуальные системы или экземпляры процессов реальной или виртуальной системы, выполняющими приложение в своем адресном пространстве в одной или разных исполнительных системах. Рассматриваемый в изобретении способ работает одинаково как при локальном взаимодействии программ, которые выполняются на одном компьютере в одной исполнительной системе, так и при взаимодействии в многопроцессорной, сетевой или другой распределенной среде в произвольной комбинации.
Исполнительные элементы могут взаимодействовать между собой. Соединения исполнительных элементов каждый с каждым не является обязательным. Изобретение поддерживает цепочки соединений через промежуточные узлы любой длины.
При использовании в локальной системе изобретение предназначено для локального взаимодействия экземпляров программ, которые выполняются в своих изолированных адресных пространствах, или имеют независимое управление ресурсами. Другим возможным применением изобретения является управление ресурсами программы, которая выполняется на нескольких исполнительных элементах.
При выполнении программы могут выделяться новые ресурсы или могут предоставляться в использование ранее выделенные ресурсы. В обоих случаях ресурсы могут рассматриваться как предоставляемые. Предоставленные любым способом ресурсы могут использоваться только определенным распределенным стеком вызовов, или ресурсы могут использоваться более чем одним распределенным стеком. Ресурсы могут быть динамическими или статическими.
Взаимодействие между исполнительными элементами основано на инструкции передачи управления, которая позволяет передать поток управления от одного исполнительного элемента другому. В типичной реализации это удаленный или локальный вызов процедуры. В зависимости от логики программы, рассматриваемая в изобретении инструкция передачи управления может передавать управление как от одного исполнительного элемента к другому, так и в границах одного исполнительного элемента. Механизм реализации удаленного или локального вызова процедуры не имеет для изобретения существенного значения. Это могут быть средства межпроцессорного взаимодействия с использованием параллельной шины, или это может быть взаимодействие на основе общей памяти, или это может быть обмен сообщениями на базе последовательной или параллельной шины или сетевой среды. Способы поиска и идентификации удаленных или локальных процедур также является не существенным для изобретения.
Заявляемое изобретение основано на управлении ресурсами с использованием стека, которое перенесено в распределенную среду. При классической организации вычислительного процесса в стеке располагают короткоживущие объекты. Объекты создаются в кадре стека процедуры и уничтожаются при возврате управления из процедуры. В настоящем изобретении для управления временем жизни объекта предлагается использовать обратную инструкцию. Основной особенностью обратной инструкции является то, что она не возвращает управление из инструкции передачи управления и не раскручивает распределенный стек. Обратная инструкция позволяет сохранять объекты стека в течение любого времени и автоматически удалять их при возврате управления из исходной инструкции передачи управления. Типичными примерами обратной инструкции могут быть удаленный или локальный вызов процедуры, которая обращается к ресурсу, и операции удаленного доступа к памяти (чтение/запись данных или атрибутов памяти). Если обратная инструкция является инструкцией передачи управления, она может продолжать или не продолжать распределенный стек вызовов. Параметры такой обратной инструкции могут содержать ссылки на ресурсы, выделенные на любом узле для этого распределенного стека вызовов. Для доступа к этим ресурсам может быть использована последующая обратная инструкция. Вызов процедуры является частным случаем инструкции передачи управления.
Предлагаемый способ управления ресурсами является:
• Простым - логика управления ресурсами совмещена с логикой потоков управления программы. При разработке программы не требуется явных инструкций освобождения ресурсов. Выделение и освобождение ресурсов выполняется локально и управление ресурсами совмещено с управлением распределенными потоками. Кроме этого, распределенный стек вызовов позволяет согласовать глобальное состояние системы при взаимодействии независимо разработанных программ.
• Надежным - освобождение неиспользуемых ресурсов является гарантированным.
• Децентрализованным - каждый распределенный стек вызовов имеет свое пространство ресурсов, и каждый узел в распределенном стеке вызовов управляет своими ресурсами. Заявленный способ может быть использован как в пиринговых системах, так и в клиент - серверных системах.
• Эффективным - одна команда возврата управления может освобождать сразу множество неиспользуемых ресурсов. Обмен сообщениями при создании и уничтожении ссылок на ресурс не требуется. Ресурсы предоставляются и освобождаются локально.
• Универсальным - предлагаемый распределенный стек является таким же универсальным, как и локальный стек.
Еще одним техническим результатом рассматриваемого способа управления ресурсами является возможность удаленного доступа к элементам памяти в случае, если исполнительная система или язык программирования не предоставляют прямого использования относительный адресации. В частности, это могут быть интерпретируемые языки программирования, например, JavaScript. Заявляемое изобретение позволяет в качестве удаленной ссылки использовать числовой индекс элемента в памяти или ключевое значение или ассоциативный адрес (например, имя переменной или функции в коде программы).
Еще одним техническим результатом является возможность ассоциировать распределенный стек вызовов с сетевыми соединениям. Это позволяет напрямую использовать сетевые сервисы ненадежной доставки данных без установления соединения. Другим преимуществом является возможность организации цепочек сетевых соединений. В частности, это позволяет гарантированно освободить ресурсы при тихом завершении любого подмножества соединений в цепочке.
Кроме этого, заявляемое изобретение устраняет все приведенные выше недостатки прототипа без потери имеющегося технического эффекта.
На фиг. 1 приведена диаграмма, иллюстрирующая заявляемое изобретение. Здесь взаимодействуют два исполнительных элемента с условными названиями Узел А и Узел Б. Инструкция с условным названием ПРИВЯЗАТЬ определяет момент, когда распределенный стек вызовов начинает выполнение на Узле А. Начиная с этого момента в интервале 10 Узел А может выделять ресурсы, которые будут доступны в этом распределенном стеке. Для примера, в этом интервале создан ОБЪЕКТ1, который является объектом в памяти с удаленно вызываемой функцией. Инструкция 11 (с условным названием SCALL) передает управление на Узел Б. Инструкция SCALL может включать информацию о ресурсах, выделенных в распределенном стеке. Такая информация может быть присоединена к сообщению удаленного вызова и/или параметры вызова процедуры могут включать явные ссылки на предоставленные ресурсы (на фиг. 1 указатель на ОБЪЕКП). На Узле Б распределенный стек начинает выполнение при получении вызова 11. В интервале 12 Узел Б может предоставлять свои ресурсы для распределенного стека. Эти ресурсы будут добавлены к ресурсам, выделенным в интервале 10. Инструкция 13 (OBbEKTl.SCALL) является обратной инструкцией, которая вызывает функцию объекта ОБЪЕКТ1. В интервале 14 доступны ресурсы, выделенные в интервалах 10 и 12. В интервале 14 Узел А получил управление по инструкции обратного вызова, а не как возврат управления из инструкции 11. В таком случае на узле А возможно два способа выделения ресурсов, которые отличаются моментом их освобождения. Блок 14.1 иллюстрирует ресурсы, указатели на которые вычисляются независимо от других ресурсов (реализация возможных типов указателей рассмотрена ниже). Такие ресурсы могут быть присоединены к ресурсам, которые выделены в интервале 10. Блок 14.2 иллюстрирует ресурсы, которые должны быть освобождены при возврате управления из инструкции 13. Инструкции 15 (ВОЗВРАТ) возвращают управление из инструкции 13. Если в интервале 14.2 были выделены ресурсы, они освобождаются. В интервале 16 доступными являются ресурсы, выделенные в интервалах 10, 12 и 14.1. Ссылки на ресурсы 14.1 могут быть переданы как возвращаемое значение в инструкции 15. Инструкция 17 (ВОЗВРАТ) возвращает управление из инструкции 11. Если в интервалах 12 и 16 были выделены ресурсы, они освобождаются.
На фиг. 1 на Узле А показаны две инструкции 11 и 19, которые выполняют начальный вызов в распределенном стеке вызовов. В интервалах 10 и 18 распределенной стек не имеет выполняемой начальной инструкции распределенной передачи управления. В интервале 18 перед начальной инструкцией в распределенном стеке вызов Узел А может выделять новые ресурсы, которые будут добавлены к ресурсам 10 и 14.1. Инструкция 19 (SCALL) выполняет еще один распределенный вызов. В интервале 110 доступны ресурсы, выделенные в интервалах 10, 14.1 и 18. Узел А является инициатором создания распределенного стека. Для завершения выполнения распределенного стека на этом узле использована инструкция с условным названием ОТВЯЗАТЬ. При этом освобождаются ресурсы, выделенные в интервалах 10, 14.1, 18 и 111 (в том числе ОБЪЕКТ1). Другим вариантом завершения работы распределенного стека вызовов на узле является возврат управления из первой инструкции передачи управления, по которой этот узел получил управление. Этот вариант показан на фиг. 1, если инструкцию ПРИВЯЗАТЬ заменить на SCALL, а инструкцию ОТВЯЗАТЬ на ВОЗВРАТ (аналогичным образом освобождаются ресурсы 12 и 16 при выполнении инструкции 17).
На фиг. 1 приведен один распределенный стек вызовов с максимальной глубиной вызовов в стеке 2. Во взаимодействии участвуют только два исполнительных элемента. Данные ограничения представлены исключительно в целях простоты изложения. В общем случае может взаимодействовать любое количество исполнительных элементов, в системе может одновременно выполняться один или более распределенных стеков вызовов, и глубина каждого распределенного стека вызовов может быть любой (глубина распределенного стека вызовов может быть ограничена разумной величиной в целях исключить зацикливание и неограниченно длинные цепочки вызовов). В частности, если фиг. 1 на Узле А вместо инструкций ПРИВЯЗАТЬ/ОТВЯЗАТЬ использовать инструкции SCALL/B03BPAT, то приведенную диаграмму можно рассматривать как фрагмент распределенного стека вызовов, который имеет любую глубину вызовов на момент получения управления Узлом А. При этом, во всех рассмотренных интервалах будут доступны ресурсы, предоставленные этому распределенному стеку вызовов на момент получения управления Узлом А.
На фиг. 1 можно выделить следующие моменты начала предоставления ресурсов на исполнительном элементе:
· Момент перед выполнением начальной инструкции распределенной передачи управления в стеке вызовов (начало интервалов 10 и 18 при использовании инструкций ПРИВЯЗАТЬ/ОТВЯЗАТЬ).
• Момент получения управления по инструкции распределенной передачи управления (начало интервалов 12, 14, 110).
· Момент возврата управления из инструкции передачи управления (начало интервалов 16, 18, 111).
Во всех случаях ресурсы на узле могут быть предоставлены в интервалах, в которых этот узел получает управление в заданном распределенном стеке вызовов. Благодаря этому предоставление ресурсов выполняется локально и не требует специального управляющего трафика между узлами системы.
На фиг. 1 можно выделить следующие моменты освобождения предоставленных ресурсов:
• Момент возврата управления из инструкции распределенной передачи управления (конец интервалов 14.2, 16, 110).
· Момент завершения работы распределенного стека вызовов на узле, к которому эти ресурсы относятся (конец интервала 111 при использовании инструкций ПРИВЯЗАТЬ/ОТВЯЗАТЬ).
• Если узел получил управление не через обратную инструкцию, то момент возврата управления из инструкции распределенной передачи управления одновременно является моментом завершения работы распределенного стека вызовов на узле (конец интервалов 16, 110, а так же конец интервала 111 при использовании инструкций SCALL B03BPAT).
Таким образом, предоставленный ресурс исполнительного элемента освобождают или модифицирует управляющую информацию при возврате управления из этого исполнительного элемента в инструкции распределенной передачи управления, или предоставленный ресурс исполнительного элемента освобождают или модифицирует управляющую информацию при завершении работы распределенного стека вызовов на этом исполнительном элементе. При этом, освобождение ресурса происходит локально и не требует передачи специальной информации между узлами системы. Одновременно освобождаются все ресурсы, которые были предоставлены для распределенного стека вызовов на исполнительном элементе.
Кроме этого, предоставленный ресурс исполнительного элемента освобождают или модифицирует управляющую информацию при выполнении инструкции программы, которая явно освобождает этот ресурс (на фиг. 1 не показано). Например, ресурс может быть явно освобожден, если это ресурс больше не нужен в программе.
Предоставляемый ресурс может принадлежать определенному стеку вызовов или ресурс может совместно использоваться разными стеками вызовов. Если каждый ресурс в системе принадлежит только одному распределенному стеку вызовов, может быть реализовано безблокировочное программирование. Для доступа к общему ресурсу может создаваться копия этого ресурса (или шлюз, или мост). Взаимодействие между копией общего ресурса и самим ресурсом может основываться на локальной асинхронной передаче сообщений.
В общем случае, освобождение ресурсов может рассматриваться как модификация управляющей информации при освобождении любого типа предоставляемых ресурсов. Например, освобождение памяти в локальном стеке выполняется через изменение значения в регистре стека, а освобождение памяти из кучи выполняется через модификацию управляющих таблиц. Для освобождения ресурсов, которые используются несколькими распределенными стеками, модифицируют управляющую информацию в счетчике ссылок или в связанном списке ссылок. Реальное освобождение ресурса происходит после того, как ресурс освобождается всеми распределенными стеками на исполнительном элементе. Если используются локальные сборщики мусора, реальное освобождение ресурса может выполняться с задержкой.
Во всех случаях, ресурсы исполнительного элемента предоставляют программе, если они являются необходимыми. Произвольное подмножество исполнительных элементов в распределенном стеке вызовов может не предоставлять ресурсы, если они не нужны. Если на исполнительном элементе не выделено ресурсов и на нем не требуется обрабатывать возврат управления в распределенном стеке вызовов, исполнительный элемент может исключить себя из распределенного стека. В этом случае он должен передать следующему исполнительному элементу информацию об исполнительном элементе, от которого он получил управление. Кроме этого, он должен передать предыдущему исполнительному элементу информацию о следующем исполнительном элементе. Если предыдущего исполнительного элемента нет (текущий исполнительный элемент является начальным), то может быть передано сообщения, означающее что возврат управления не требуется.
Особенностью рассматриваемого способа управления ресурсами является гарантированное освобождение ресурсов при завершении работы распределенного стека вызовов. Распределенный стек может быть завершен следующими способами: · Завершение назад. Данный способ выполняется при нормальном возвращении управления из инструкции передачи управления или при возврате управления через исключение. При завершении всего стека вызовов распределенный стек последовательно раскручивается назад с освобождением ресурсов исполнительных элементов в цепочке вызовов.
· Завершение вперед. Этот способ используется, если инициатором завершения является исполнительный элемент, который в данный момент не находится на вершине распределенного стека вызовов. В этом случае раскрутка стека не происходит, а посылается специальное сообщение завершения стека. Это сообщение последовательно передается по цепочке вызовов от инициатора завершения до исполнительного элемента в вершине распределенного стека вызовов (если это возможно). Каждый исполнительный элемент при получении сообщения о завершении распределенного стека должен освободить ресурсы, которые предоставлены этому стеку.
Выполнение распределенного стека может быть завершено любым узлом в цепочке вызовов. Если инициатор завершения находится не на концах цепочки распределенного стека вызовов, одновременно выполняется завершение вперед и назад. Завершение назад может выполняться через возбуждение исключения. Рассматриваемые способы завершения позволяют гарантированно освободить ресурсы распределенного стека при одновременном отключении произвольного подмножества узлов в цепочке вызовов.
Еще одним техническим результатом использования заявляемого изобретения является согласованное глобальное состояние стека при взаимодействии независимо разработанных программ. При взаимодействии обычных программ с использованием локального или удаленного вызова процедуры (RPC / LPC) каждая программа фактически является самостоятельным конечным автоматом со своим набор переменных состояния и своей логикой переходов. Вызовы RPC / LPC реализуются как слабо - связанное взаимодействие, основанное на обмене сообщениями. В результате глобальное состояние системы и глобальная логика работы являются трудно предсказуемыми. Это повышает сложность разработки и уменьшает надежность. В заявляемом изобретении ресурсы, предоставленные в стеке, можно рассматривать как переменные состояния. В типичном случае, ссылки на эти ресурсы передаются между исполнительными элементами как параметры вызовов и возвращаемые значения процедур RPC / LPC. Таким образом, ресурсы, которые определяют состояние распределенного стека вызовов, известны и являются частью протокола взаимодействия. Ресурсы распределенного стека могут быть логически изолированы от переменных состояния отдельных программ. Переменные состояния распределенного стека могут определять как глобальное состояние всего стека, так и состояние отдельных соединений или отдельного подмножества цепочек соединений. Изменение состояния выполняется через обратную инструкцию и является составной частью протокола взаимодействия. В частности, это позволяет легко разрабатывать распределенные приложения, логика которых основана на состоянии связей между множеством узлов. Еще одним вариантом является использование изобретения при взаимодействии программ с плохо управляемым состоянием, например, Web - страниц.
Краткое описание чертежей
Фиг. 1. Диаграмма, которая иллюстрирует изобретение. Фиг. 2. Схема реализации системы в соответствии с изобретением.
Осуществление изобретения
На фиг. 2 приведена схема возможной реализации заявляемого изобретения.
Рассматриваемая реализация описана на примере программы, разработанной на стандартном языке С++. Этот язык позволяет реализовать любое управление ресурсами и любую организацию вычислительным процессом. Однако заявляемое изобретения является независимым от платформы и используемого языка программирования. Оно может быть реализовано на множестве платформ и интегрировано с различными компилируемыми и интерпретируемыми языками программирования в произвольном сочетании. Например, в качестве возможной реализации на интерпретируемом языке программирования может быть предложен JavaScript.
На фиг. 2 метки 21, 22 указывают на прикладные программы, разработанные на
С++. Это могут быть разные программы или копия одной программы. Программы разработаны с использованием библиотеки шаблонов С++ um.h - 23, 24. Эта библиотека создана на основе заявляемого изобретения. Она включает набор шаблонов, которые являются расширением языка и позволяют скрыть на уровне исходного текста программы детали распределенного взаимодействия. Шаблоны из библиотеки um.h взаимодействует с системной службой 25, 26. Системная служба реализует логику настоящего изобретения. Программы выполняются на исполнительных элементах - компьютерах с условными названиями УЗЕЛ А, УЗЕЛ Б и УЗЛЫ N-N. Компьютеры связаны через сеть 27. Рассматриваемая реализация позволяет взаимодействовать программам, выполняемым на одном или разных компьютерах в произвольной комбинации.
Системная служба 25, 26 является расширением операционной системы. Она реализует собственный протокол удаленного и локального вызова процедуры (RPC и LPC) в соответствии с настоящим изобретением. Конкретная реализация RPC и LPC является не существенной для изобретения. RPC и LPC являются хорошо известными технологиями взаимодействия программ, которые имеют множество частных и стандартизованных реализаций.
Организация вычислительного процесса в рассматриваемой системе включает два типа потоков управления программы. Это локальные потоки управления и распределенные потоки управления. Распределенный поток управления определяется цепочкой вызовов RPC / LPC и выполняется в контексте распределенного стека вызовов. Когда распределенный поток управления выполняется на определенном исполнительном элементе, его выполняет некоторый локальный поток управления. Возможны следующие варианты реализации связи локальных и распределенных потоков управления:
• Распределенный поток ассоциируют с определенным локальным потоком. При такой связи распределенный поток является цепочкой определенных локальных потоков. Вызовы RPC / LPC выполняются синхронно. Локальный поток освобождается, когда он возвращает управление из распределенного вызова. Данный способ является простым и хорошо подходит для пиринговых и клиентских систем. Недостатком этого способа является плохое масштабирование в серверных системах, которые одновременно обрабатывают большое количество запросов. • Распределенный поток выполняется на определенном узле в контексте некоторого локального потока управления. Если распределенный поток управления приостанавливает свое выполнение или выполняет вызов RPC / LPC, освобожденный локальный поток управления может выполнять другой распределенный поток управления. Такой способ поддерживает асинхронные вызовы и хорошо масштабируется в серверных системах.
Реализация указанных способов обработки запросов является хорошо известной для большинства исполнительных систем.
В рассматриваемой реализации для управления распределенным стеком вызовов на локальном компьютере в памяти компьютера создается специальная управляющая структура. Эта структура включает уникальный идентификатор распределенного стека вызовов, адрес предыдущего и следующего узла в распределенном стеке вызовов, ссылки на ресурсы, которые выделены на узле для этого стека, информацию об используемых сетевых соединениях и другую информацию. Данная управляющая структура в явном или неявном виде участвует в операциях с распределенным стеком вызовов.
Следующий пример минимальной программы иллюстрирует использование заявляемого изобретения. Данный пример никак не ограничивает изобретение и приведен исключительно для иллюстрации рассматриваемой реализации. Возможно множество других реализаций кода в соответствии с заявляемым изобретением. В рассматриваемом примере взаимодействуют два узла с условными названиями Узел А и Узел Б. Сетевой адрес Узла А является несущественным для данного примера. Узел Б имеет условный сетевой адрес 10.0.1.28. На Узле А выполняется программа со следующим исходным текстом:
1 #include "um.h"
2 class Objectl {
3 void functHello (const char* s_out) { 4 printf (s_out) ;
5 }
6 };
7 void runHello (uptr<Objectl>) {}
8 void main ( ) {
9 UM_ADD_FUN (Objectl : : functHello) ;
10 UM_ADD_FUN ( runHe1lo) ;
11 UMDS* ds = InitDStack () ;
12 BindDStack(ds) ;
13 uptr<Objectl> ptr = amake<Objectl> ( ) ;
14 scall ("10.0.1.28", runHello, ptr);
15 UnbindDStack(ds) ;
16 }
На Узле Б выполняется программа со следующим исходным текстом:
17 #include "um.h"
18 class Objectl {
19 void functHello (const char*) {}
20 };
21 void runHello (uptr<Objectl> ptr) {
22 ptr. scall (functHello, "Hello, World!");
23 }
24 void main() {
25 UM_ADD_FUN (Objectl : : functHello) ;
26 UM_ADD_FUN (runHe11о) ;
27 RunDStackO;
28 }
Строки 1, 17 включают описанную выше библиотеку шаблонов um.h. Строки 2 - 6 определяют объект, который будет создан как ресурс для обратного вызова. Строка 7 определяет функцию - заглушку для удаленного вызова, которая используется как прототип при формировании удаленного вызова. В строках 9, 10 и 25, 26 регистрируются процедуры для удаленных вызовов. В строке 11 функция InitDStack ( ) инициализирует распределенный стек. При этом создается структура UMDS, которая будет управлять выполнением распределенного стека на Узле А. В строке 12 функция BindDStack () связывает инициализированный распределенный стек с текущим локальным потоком управления программы. Для связи локального и распределенного потока функция BindDStack () записывает указатель на структуру UMDS в специальную переменную, которая расположена в определенном месте в локальной памяти потока. В зависимости от используемой архитектуры системы и среды выполнения могут быть использованы другие способы связи локального и распределенного потока управления. В строке 13 в динамической памяти создается объект типа Object1, который является предоставленным ресурсом. Индекс этого объекта в памяти, выделенной для текущего распределенного стека, записывается в специальный распределенный указатель uptro. Данный тип указателей реализован как шаблон в библиотеке um.h. Типы указателей, используемые для адресации памяти распределенного стека вызовов, описаны ниже. Ссылка на предоставленный объект связывается с управляющей структурой UMDS для последующего автоматического освобождения ресурсов. Строка 14 содержит удаленный вызов функции runHello ( ) на Узле Б. Этот вызов является начальным в стеке ds. В этом вызове передается распределенный указатель на объект Objectl.
На Узле Б в строке 27 функция RunDStack () передает локальный поток управления функции main() для обработки входящих вызовов RPC / LPC. При получении входящего вызова RPC создается структура управления распределенным стеком на Узле Б. Эта структура инициализируется значениями из входящего запроса RPC / LPC. В данном примере в контексте принятого распределенного стека выполняется функция runHello ( ) . Строка 22 содержит обратную инструкцию, которая удаленно вызывает метод functHello ( ) объекта Objectl на Узле А.
Поток функции main ( ) на Узле А находится в состоянии ожидания и выполняет входящий вызов RPC метода functHello (). После этого управление возвращается на Узел Б. Затем функция runHello () завершает выполнение и управление возвращается на Узел А. На Узле А в строке 15 функция UnbindDStack ( ) завершает выполнение распределенного стека вызовов. При этом созданный объект Objectl автоматически удаляется.
Рассматриваемый пример программы содержит синхронные удаленные вызовы процедур, которые являются более простыми для иллюстрации. В общем случае удаленные вызовы процедур могут быть синхронными или асинхронными. Возможный вариант реализации асинхронного вызова может включать специальную функцию, ссылка на которую передается в исходном удаленном вызове процедуры. Обратный вызов этой функции означает возврат управления в соответствующей инструкции удаленного вызова. Эта функция может иметь параметр, совпадающий с возвращаемым значением вызываемой процедуры. В качестве другого параметра может выступать объект, сигнализирующий об исключительной ситуации. Кроме этого, существуют другие известные варианты реализации асинхронных вызов процедур. Асинхронный вызов может продолжать или не продолжать распределенный стек вызовов.
Для того чтобы один исполнительный элемент мог обратиться к ресурсам другого исполнительного элемента, информация о ресурсах может передаваться:
• в параметрах вызова локальной или удаленной процедуры и/или
• как составная часть самой инструкции передачи управления и/или
• в возвращаемых значениях обратной инструкции (например, инструкции чтения памяти) и/или
• в возвращаемом значении инструкции вызова процедуры и/или
• такая информация может быть определена в протоколе взаимодействия исполнительных элементов на этапе разработки и/или настройки исполняемой программы.
Для адресации ресурсов могут быть использованы распределенные указатели
(ссылки). Возможным вариантом адресации ресурсов является способ, при котором ресурсы, которые предоставляются в распределенном стеке, последовательно добавляется к совокупности предоставленных ресурсов в этом распределенном стеке. Вся совокупность предоставленных стеку ресурсов рассматривается как единое пространство.
Если в качестве ресурса используется память, то в качестве распределенного адреса ресурса может быть использовано смещение от начала выделенной в распределенном стеке вызовов памяти (так, как это предложено в прототипе). Более универсальным способом, который предложен в заявляемом изобретении, является использование числового индекса ресурса. Каждому выделенному в распределенном стеке ресурсу присваивается последовательный числовой индекс. Текущий максимальный индекс ресурсов, выделенных в распределенном стеке, передается в инструкции передачи управления. Использование индекса в качестве распределенного указателя позволяет, во-первых, адресовать ресурсы, которые занимают в памяти различную длину, во-вторых, в качестве ресурсов может использоваться не только память (например, дескрипторы системных объектов или других программных или аппаратных объектов).
Возможный вариант технической реализации является следующим: индекс или распределенный адрес связывается с локальным идентификатором ресурса на основании управляющей таблицы (или управляющего связанного списка). Каждый исполнительный элемент имеет свою часть таблицы для своих ресурсов определенного распределенного стека вызовов. Строка таблица связывает распределенный адрес или индекс с локальным адресом памяти этого ресурса (или другим локальным идентификатором ресурса). Если код приложения обращается к ресурсу, исполнительный элемент ищет этот ресурс в управляющей таблице по его распределенному адресу или индексу. Если он не находит ресурс в своей управляющей таблице, он обращается к предыдущему в распределенном стеке вызовов исполнительному элементу. Если ресурс принадлежит предыдущему исполнительному элементу, этот исполнительный элемент обращается к ресурсу. Иначе предыдущий исполнительный элемент обращается к своему предыдущему в стеке вызовов исполнительному элементу.
В заявляемом изобретении, кроме числового индекса массива, можно использовать индексы другого типа, например, строковые. Такой индекс не обязательно является уникальным. В качестве индекса можно использовать имя переменной, имя функции или имя объекта. Алгоритм поиска ресурсов на определенном исполнительном элементе является несущественным для изобретения. Например, алгоритм может определяться логикой областей видимости переменных. Если исполнительный элемент не находит ресурс в своей памяти, он обращается к предыдущему в стеке вызовов исполнительному элементу.
Еще одним вариантом реализации распределенных указателей в заявляемом изобретении является ассоциативная адресация. В этом варианте поиск ресурса ведется в совокупности выделенной распределенному стеку памяти, на основании ассоциативного адреса. Ресурсом может быть память, в которой расположен код или фрагмент кода программы, или динамические данные, или другие ресурсы. Указанные выше управляющие таблицы в этом случае не требуются. Последовательность поиска на отдельном исполнительном элементе определяется типом ассоциативной адресации. Например, если ресурсом является процедура или переменная в памяти, поиск может вестись по имени в соответствии с правилами видимости имен языка программирования. Процедура программы может рассматриваться как статический ресурс. Если исполнительный элемент не находит ресурс в своей памяти, он обращается к предыдущему в сетке вызовов исполнительному элементу.
Строковый индекс или ассоциативный адрес позволяет связать ресурс с его идентификатором на этапе разработки или настройки программы. В этом случае идентификатор ресурса может быть определен в протоколе взаимодействия исполнительных элементов. Обмен информацией между исполнительными элементами для использования такого ресурса не требуется.
Если предоставляемым ресурсом является память, то для описанных выше управляющих таблиц тип памяти не имеет значения. Обычно память любого типа расположена в одном локальном адресном пространстве. Это может быть память из локального стека локального потока управления (с которым ассоциирован распределенный стек вызовов), динамическая память из кучи, или статическая память. От типа предоставляемой памяти зависит то, как она должна освобождаться.
Память из локального стека удаляется автоматически при раскрутке распределенного стека вызовов.
Динамическая память может одновременно использоваться несколькими распределенными стеками вызовов. Для освобождения динамической памяти могут быть использованы локальные счетчики ссылок, локальные связанные списки ссылок, или локальные сборщики мусора. При этом сами ссылки на ресурсы должны принадлежать определенным распределенным стекам вызовов. В общем случае, распределенная ссылка на один и тот же ресурс в разных распределенных стеках может иметь разное значение распределенного адреса. Для того, чтобы ссылка на ресурс одного распределенного стека не была использована в другом распределенном стеке, ссылка может включать указатель на управляющую структуру своего распределенного стека, или ссылка может включать идентификатор распределенного стека. Ссылки удаляются при завершении работы распределенного стека на данном исполнительном элементе. При этом модифицируется управляющая информация, которой могут являться счетчики ссылок или связанные списки. Если все распределенные стеки вызовов, которые используют ресурс, завершают работу на исполнительном элементе, то используемая динамическая память автоматически освобождается. При этом управление ссылками является полностью локальным и не требует передачи сообщений между узлами системы.
Для статической памяти может вестись учет распределенных стеков, которые используют эту память в данный момент. Освобождение памяти в этом случае означает модификацию управляющей информации. Статические ресурсы могут предоставляться для использования в распределенных стеках и никогда фактически не освобождаться.
Еще одним известным вариантом технической реализации распределенных указателей на ресурсы является специальный указатель (ссылка), который включает адрес исполнительного элемента и локальный идентификатор ресурса (например, локальный адрес памяти). В качестве адреса исполнительного элемента может быть использован сетевой адрес узла, или номер процессора, или совокупность идентификатора процесса и адреса исполнительного элемента, или виртуальный адрес, или что-то другое. Каждый такой указатель содержит полную информацию о ресурсе и не зависит от других предоставленных ресурсов (то есть, предоставленные ресурсы не нужно рассматривать как единую совокупность). Для использования таких распределенных указателей не требуются описанные выше управляющие таблицы. Кроме этого, в инструкции передачи управления не требуется передавать специальную управляющую информацию. Один исполнительный элемент может обратиться к ресурсу другого исполнительного элемента через сетевой адрес исполнительного элемента, который содержится в распределенном указателе. Такие указатели могут просто передаваться в параметрах или в возвращаемых значениях распределенных вызовов процедур.
В большинстве реальных систем одновременно существует более одного распределенного стека вызовов. Заявляемое изобретение предлагает для идентификации каждого выполняемого распределенного стека использовать уникальный идентификатор. Этот идентификатор является уникальным в вычислительной системе на время выполнения распределенного стека вызовов. Он должен передаваться в инструкции распределенной передачи управления (например, как часть управляющей информации). Отсутствие идентификатора может рассматриваться как NULL - значение, которое может быть присвоено одному распределенному стеку вызовов. В частности, NULL - значение может быть использовано в системе, в которой выполняется только один распределенный стек вызовов.
Существуют известные способы создания уникальных идентификаторов. Если все узлы системы имеют уникальные адреса, то для идентификатора распределенного стека может быть использована простая комбинация адреса узла и короткого идентификатора, который является уникальным на этом узле в данный момент времени. Если система включает множество независимых сетей, то может быть использован стандартный 16 - байтный глобально - уникальный идентификатор (GUID).
Другим вариантом идентификатора является цифровая подпись известной информации и/или информации, передаваемой одновременно с уникальным идентификатором. Цифровая подпись как идентификатор может передаваться полностью или в усеченном виде (для уменьшения объема трафика). Техническим результатом использования цифровой подписи является возможность идентифицировать компьютер или пользователя, который инициировал выполнение распределенного стека вызовов. Также возможно вложение цифровых подписей в цепочке вызовов распределенного стека.
Уникальный идентификатор распределенного стека позволяет рассматривать стек как полудуплексное соединение, которое соединяет любое количество узлов системы. Узел, который в данный момент получил управление, является активным. Он может вызвать процедуру другого узла или вернуть управление из инструкции распределенной передачи управления. Остальные узлы стека вызовов являются пассивными. Пассивный узел может стать активным при возврате управления из выполняемой инструкции передачи управления или при получении входящего распределенного вызова процедуры. Для реализации полностью дуплексного взаимодействия между двумя узлами могут быть установлены два встречных распределенных стека вызовов с совместно используемыми ресурсами.
Во всех случаях, заявляемый способ работоспособен без уникального идентификатора распределенного стека вызовов. Исполнительный элемент хранит информацию о предыдущем в стеке вызовов исполнительном элементе. Обратная инструкция может предаваться назад по цепочке вызовов до исполнительного элемента владельца ресурса. Идентификация стека между каждой парой узлов в цепочке вызовов является достаточной. Если система поддерживает сквозную идентификацию цепочек соединений между исполнительными элементами, распределенный стек может быть ассоциирован с определенным соединением. В этом случае отдельный идентификатор распределенного стека так же не требуется.
Типичное взаимодействие в клиент - серверной системе в соответствии с заявляемым изобретением включает следующие шаги:
1) Клиент выделяет ресурс (объект или функцию) для обратного вызова и удаленно вызывает процедуру сервера.
2) Сервер предоставляет необходимый клиенту ресурс и передает ссылку на него в обратном вызове.
3) Клиент удаленно вызывает предоставленный на сервере ресурс в инструкции обратного вызова.
Такая последовательность полностью соответствует классическому трех - шаговому установлению сетевого соединения. Это позволяет напрямую использовать ненадежный сервис без установления соединений для передачи сообщений между исполнительными элементами (например, UDP или Ethernet). Техническим результатом является возможность передавать данные, начиная с первой команды установления соединения. Для реализации этой идеи рассматриваемая выше управляющая структура распределенного стека может быть дополнена переменными и таймерами повторной передачи, которые определяют состояние соединения. К информации, передаваемой в удаленном вызове, нужно добавить порядковый номер сообщения. Кроме этого, нужно осуществлять повторную передачу при отсутствии подтверждения по тайм-ауту. Еще одним техническим результатом является возможность использования заявляемого способа для реализации сетевых протоколов с установлением соединения. В этом случае распределенный стек вызовов передает данные других приложений, а предоставляемыми ресурсами являются протокольные конечные автоматы.
Как было отмечено выше, заявляемый способ является универсальным и может быть использован для решения множества различных задач. Рассмотренная реализация изобретения является далеко не единственно возможной. Возможно множество других реализаций в различных исполнительных системах и в различных реализациях удаленных и локальных вызовов процедур. Можно с уверенностью утверждать, что любая реализация RPC и LPC может быть расширена в соответствии с заявляемым изобретением.

Claims

Формула изобретения
1. Способ управления ресурсами в вычислительной системе, включающей один или более взаимодействующих исполнительных элементов, в которой используют инструкцию передачи управления, которая позволяет передать управление между исполнительными элементами таким образом, что последовательность одной или более выполняемых инструкций передачи управления образует распределенный стек вызовов, указанный способ, отличающийся тем, что один или более ресурс, связанный с исполнительным элементом, предоставляют, когда этот исполнительный элемент получает управление в указанном распределенном стеке вызовов или перед исполнением начальной инструкции передачи управления в указанном распределенном стеке вызовов, для доступа на одном исполнительном элементе к указанному ресурсу другого исполнительного элемента выполняют обратную инструкцию, и указанный ресурс исполнительного элемента освобождают или модифицируют управляющую информацию, в случае возврата управления из этого исполнительного элемента в указанной инструкции передачи управления, или в случае завершения работы указанного стека вызовов на этом исполнительном элементе, или в случае выполнения инструкции программы, которая явно освобождает этот ресурс.
2. Способ по п. 1, отличающийся тем, что указанные исполнительные элементы являются в произвольной комбинации ядрами в многоядерной системе, или процессорами в многопроцессорной системе, или процессорами компьютеров, соединенными через сеть, или реализованными программно виртуальными системами, или экземплярами процессов реальной или виртуальной системы, выполняющими программу в одной или более исполнительных системах.
3. Способ по п. 1, отличающийся тем, что указанная инструкция передачи управления является инструкцией локального или удаленного вызова процедуры.
4. Способ по п. 1, отличающийся тем, что указанная обратная инструкция является инструкцией передачи управления.
5. Способ по п. 1, отличающийся тем, что указанная обратная инструкция является инструкцией локального или удаленного вызова процедуры.
6. Способ по п. 1, отличающийся тем, что указанная обратная инструкция является инструкцией доступа к памяти.
7. Способ по п. 1, отличающийся тем, что ресурсы, предоставленные указанному распределенному стеку вызовов, рассматривают как единую совокупность, являющуюся объединением этих ресурсов, при выполнении операции доступа к элементам указанной совокупности исполнительный элемент контролирует выход за границы своего подмножества ресурсов, если указанный исполнительный элемент обнаруживает выход за границы своего подмножества ресурсов, он обращается к предыдущему в указанном стеке вызовов исполнительному элементу, предыдущий в стеке вызовов исполнительный элемент выполняет операцию доступа к ресурсу, если этот ресурс связан с этим исполнительным элементом, или обращается к своему предыдущему исполнительному элементу в указанном стеке вызовов.
8. Способ по п. 7, отличающийся тем, что указанный предоставляемый ресурс является элементом памяти, связанным с указанным исполнительным элементом.
9. Способ по п. 8, отличающийся тем, что совокупность памяти, которая предоставлена для указанного распределенного стека вызовов, рассматривают как непрерывную память или как массив с элементами постоянной или переменной длины, общий размер или максимальный индекс массива текущей указанной совокупности памяти передают при выполнении указанной инструкции передачи управления, для адресации в указанной совокупности памяти используют относительный адрес или индекс, которые рассчитывают от начала указанной совокупности памяти.
10. Способ по п. 7, отличающийся тем, что указанная совокупность ресурсов, является памятью с ассоциативной адресацией или совокупностью пар ключ (уникальный или не уникальный) - значение.
11. Способ по п. 7, отличающийся тем, что указанным предоставляемым ресурсом является память, в которой расположена выполняемая программа или фрагмент программы.
12. Способ по п. 1, отличающийся тем, что информацию, необходимую для использования указанных ресурсов, передают в параметрах вызова, или возвращаемом значении указанной инструкции передачи управления, или в возвращаемом значении указанной обратной инструкции, или эту информацию передают как составную часть самой инструкции передачи управления, или эту информацию определяют в протоколе взаимодействия исполнительных элементов.
13. Способ по п. 1, отличающийся тем, что указанный стек вызовов завершают на определенном исполнительном элементе при возврате управления из этого исполнительного элемента в указанной инструкции передачи управления в указанном стеке вызовов, или указанный стек вызовов завершают на определенном исполнительном элементе при получении сообщения о необходимости завершения указанного стека вызовов, или указанный стек вызовов завершают на определенном исполнительном элементе при выполнении инструкции программы.
14. Способ по п. 1, отличающийся тем, что возврат управления из указанной инструкции передачи управления выполняют как вызов процедуры, информацию о которой передают при выполнении инструкции передачи управления, из которой выполняют возврат.
15. Способ по п. 1, отличающийся тем, что при выполнении указанной инструкции передачи управления между указанными исполнительными элементами передают идентификационную информацию пользователя или компьютера, который инициировал исполнение указанного распределенного стека вызовов.
16. Способ по п. 1, отличающийся тем, что каждому выполняемому указанному распределенному стеку вызовов присваивают идентификатор, который является уникальным в указанной вычислительной системе на время выполнения этого стека вызовов, включая отсутствие идентификатора как одно из возможных значений.
17. Способ по п. 16, отличающийся тем, что в качестве указанного идентификатора распределенного стека используют цифровую подпись в полном или усеченном виде.
18. Способ по п. 1, отличающийся тем, что ресурсы не предоставляют на любом подмножестве исполнительных элементов в указанном распределенном стеке вызовов, если ресурсы указанного подмножества не являются необходимыми.
19. Способ по п. 18, отличающийся тем, что если исполнительный элемент не предоставил ресурсы, то этот исполнительный элемент исключают из указанного стека вызовов, передав следующему в стеке вызовов исполнительному элементу информацию о предыдущем в стеке вызовов исполнительном элементе и передав предыдущему в стеке вызовов исполнительному элементу информацию о следующем в стеке вызовов исполнительном элементе, если предыдущий исполнительный элемент есть в указанном стеке вызовов.
20. Способ по п. 1, отличающийся тем, что предоставляемые ресурсы частично или полностью совместно используют в более чем в одном распределенном стеке вызовов.
21. Способ по п. 1, отличающийся тем, что указанный распределенный стек вызов ассоциируют с соединениями между исполнительными элементами в этом стеке вызовов.
22. Способ по п. 1, отличающийся тем, что указанную инструкцию передачи управления выполняют синхронно.
23. Способ по п. 1, отличающийся тем, что указанную инструкцию передачи управления выполняют асинхронно.
24. Способ по п. 1, отличающийся тем, что указанным предоставляемым ресурсом является объект, функцию которого вызывают в указанной обратной инструкции.
25. Способ по п. 1, отличающийся тем, что в качестве информации, необходимой для использования указанного ресурса, используют распределенный указатель на ресурсы.
26. Способ по п. 25, отличающийся тем, что указанный указатель на ресурсы включает смещение или индекс или идентификатор ресурса в совокупности ресурсов, предоставленных в указанном распределенном стеке вызовов.
27. Способ по п. 25, отличающийся тем, что указанный указатель на ресурсы включает комбинацию адреса исполнительного элемента и локального идентификатора ресурса.
28. Способ по п. 1, отличающийся тем, что указанные предоставляемые ресурсы рассматривают как переменные состояния указанного распределенного стека вызовов.
PCT/RU2013/000575 2012-07-10 2013-07-05 Способ управления ресурсами в вычислительной системе WO2014011084A1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2012128956 2012-07-10
RU2012128956/08A RU2012128956A (ru) 2012-07-10 2012-07-10 Способ управления ресурсами в вычислительной системе

Publications (1)

Publication Number Publication Date
WO2014011084A1 true WO2014011084A1 (ru) 2014-01-16

Family

ID=49916386

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2013/000575 WO2014011084A1 (ru) 2012-07-10 2013-07-05 Способ управления ресурсами в вычислительной системе

Country Status (2)

Country Link
RU (1) RU2012128956A (ru)
WO (1) WO2014011084A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110431806A (zh) * 2017-04-19 2019-11-08 华为技术有限公司 分布式资源管理中低时延节点本地调度的系统和方法
CN113326155A (zh) * 2021-06-28 2021-08-31 深信服科技股份有限公司 一种信息处理方法、装置、系统和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050240795A1 (en) * 2004-04-27 2005-10-27 Nokia Corporation Resource management system and method
US6966033B1 (en) * 2001-09-28 2005-11-15 Emc Corporation Methods and apparatus for graphically managing resources
US7032186B1 (en) * 2001-09-28 2006-04-18 Emc Corporation Methods and apparatus for representing resources in a computing system environment
US20060190482A1 (en) * 2005-02-22 2006-08-24 Microsoft Corporation Method and system for resource management

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6966033B1 (en) * 2001-09-28 2005-11-15 Emc Corporation Methods and apparatus for graphically managing resources
US7032186B1 (en) * 2001-09-28 2006-04-18 Emc Corporation Methods and apparatus for representing resources in a computing system environment
US20050240795A1 (en) * 2004-04-27 2005-10-27 Nokia Corporation Resource management system and method
US20060190482A1 (en) * 2005-02-22 2006-08-24 Microsoft Corporation Method and system for resource management

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110431806A (zh) * 2017-04-19 2019-11-08 华为技术有限公司 分布式资源管理中低时延节点本地调度的系统和方法
US11561830B2 (en) 2017-04-19 2023-01-24 Huawei Technologies Co., Ltd. System and method for low latency node local scheduling in distributed resource management
CN113326155A (zh) * 2021-06-28 2021-08-31 深信服科技股份有限公司 一种信息处理方法、装置、系统和存储介质
CN113326155B (zh) * 2021-06-28 2023-09-05 深信服科技股份有限公司 一种信息处理方法、装置、系统和存储介质

Also Published As

Publication number Publication date
RU2012128956A (ru) 2014-01-20

Similar Documents

Publication Publication Date Title
CN100580628C (zh) 操作系统友好引导加载器
US8270299B2 (en) Communicator-based token/buffer management for eager protocol support in collective communication operations
RU2285947C2 (ru) Способ обеспечения безопасности с детерминированным выполнением в реальном времени многозадачных приложений типа управление-регулирование с локализацией ошибок
Demmer et al. The arrow distributed directory protocol
US8813093B2 (en) Integration of disparate applications on a network
US20060026169A1 (en) Communication method with reduced response time in a distributed data processing system
EP3295293B1 (en) Thread safe lock-free concurrent write operations for use with multi-threaded in-line logging
RU2003113302A (ru) Способ защиты с детерминированным выполнением в режиме реального времени многозадачных приложений управленческого и контрольного типа с ограничением ошибок
CN106776395B (zh) 一种共享集群的任务调度方法及装置
WO2020232875A1 (zh) 一种基于Actor模型的任务调度方法、装置及存储介质
US20200409841A1 (en) Multi-threaded pause-less replicating garbage collection
WO2023124945A1 (zh) 多方数据处理方法、系统、电子装置和存储介质
CN105242872A (zh) 一种面向虚拟集群的共享存储系统
Bertogna et al. Static-priority scheduling and resource hold times
WO2014011084A1 (ru) Способ управления ресурсами в вычислительной системе
WO2016008317A1 (zh) 数据处理方法和中心节点
Elwakil et al. Debugging support tool for MCAPI applications
CN112395056A (zh) 一种嵌入式非对称实时系统及电力二次设备
CN110445580A (zh) 数据发送方法及装置、存储介质、电子装置
RU2554509C2 (ru) Система и способ распределенных вычислений
CN108415779A (zh) 用于通过主机结构接口的队列管理的技术
CN114281529A (zh) 分布式虚拟化的客户操作系统调度优化方法、系统及终端
Henrio et al. Declarative scheduling for active objects
Currin et al. Mobile process calculi for programming the blockchain documentation
Yong et al. KQML realization algorithms for agent communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13816881

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13816881

Country of ref document: EP

Kind code of ref document: A1