MX2008005402A - Statically verifiable inter-process-communicative isolated processes - Google Patents

Abstract

Described herein are one or more implementations of an operating system that provides for statically verifiable inter-process communication between isolated processes (230, 240, and 250). Also, described herein are one or more implementations of programming tools that facilitate the development of statically verifiable isolated processes having inter-process communication.

Description

PROCESSES ISOLATED COMMUNICATIVE BETWEEN PROCESSES, STATICLY VERIFIABLE BACKGROUND Some operating systems (OSs) provide process isolation and communication between processes OSs try to isolate a process so that it can not access or corrupt data or execute instructions from another process. In addition, isolation provides clear limits to close a process and reclaim its resources without the cooperation of other processes The communication between processes allows the processes to exchange data and signal events. However, there is a natural tension between isolation and communication between processes. Typically, the more isolated the processes are from one another, the more complicated and potentially expensive it can be. be for processes to communicate with each other Conversely, the less isolated the processes are from each other, the easier it is for processes to communicate with each other For example, processes that share memory can be considered to have a low degree of isolation Shared memory processes can typically communicate with nicarse in a seemingly simple way just to write and read directly to / from shared memory If, on the other hand, an OS does not allow processes to share memory, the OS typically provides some mechanism for processes to exchange information By reference to performance considerations, the exchanges between isolation and communication are solved conventionally in a way that sacrifices the benefits of isolation. In particular, conventional OSs often allow shared memory between processes. Thus, OSs even co-locate components within the same process to maximize communication. Examples of such co-location are device drivers, browser extensions, and web service connectors. Absorbing the process isolation for such ease of access to such components can complicate or describe many of all the benefits of isolation, such as fault diameter and clear resource management. When a component fails, the failure frequently leaves shared memory in an inconsistent or corrupted state that can present the rest of the inoperable components. At the other end of the spectrum, truly isolated processes, of course, enjoy the benefits of isolation. However, such isolated processes conventionally deal with communication between processes.

BRIEF DESCRIPTION OF THE INVENTION Here we describe one or more implementations of an operating system that provides communication between statically verifiable process between isolated processes. Also, here we describe one or more implementations of programming tools that facilitate the development of statically vepfiable isolated processes that have communication between processes This brief description is provided to introduce a selection of concepts in a simplified form that is also described later in the detailed description This brief description does not intend to identify key characteristics or essential characteristics of the subject claimed, or intended to be used as an aid in determining the scope of the claimed item BRIEF DESCRIPTION OF THE DRAWINGS The same numbers are used throughout the drawings to refer to similar elements and features Figure 1 is an operational scenario for an operating system architecture that supports one or more implementations described here Figure 2 is another operational scenario for an architecture of operating system supporting one or more implementations described herein Figure 3 is a block diagram of an operating system architecture that supports one or more implementations described herein Figure 4 is a flow chart of another methodological implementation described herein Figure 5 is a flow chart of another implementation methodological described here DETAILED DESCRIPTION The following description mentions an operating system (OS) that provides isolated processes that have capacity for communication between processes. The isolation of the isolated processes of the OS described among this is statically vepficable The executable instructions of the isolated process can be verified in time of collection or time of operation or both Also, here is described, one or more programming language tools that facilitate the development of communication between statically vepficable process between isolated processes A statically vepficable process is a software process whose executable instructions can be analyzed without actually executing the instructions of process The analysis ensures that the process will not behave in unauthorized ways and / or interfere with the operation of other processes or the same operating system One or more implementations described here are used in programming language tools for rear an environment in which software is more likely to be built better, program behavior is easier to verify, and performance-type failures can be contained and lightened. Some of the features of one or more implementations described here include (but are not they are limited to) • The data is exchanged through bidirectional channels, where each channel consists of exactly two endpoints. At any moment of time, each channel end point is obtained by an individual sequence (that is, obtained by an individual process) • Memories intermediates and other memory data structures are transferred by the pointer, instead of copying the data contained in the buffers and memory data structures These transfers pass the ownership of memory blocks • Channel communication is governed by channel contracts statically vepficables describing messages, message argument types, and valid message interaction sequences such as finite state machines similar to session types • Channel endpoints can be sent in messages on channels In this way, the communication network can evolve dynamically • Send and receive a channel that does not require memory distribution • Shipments are non-blocking and do not fail. No blocking means that the shipment does not wait for communication to succeed. Does not fail means that the communication always succeeds eventually. The implementation accomplishes this by definition. A shipping operation is completed without waiting for results ( However, a "channel" can fail and this can be observed when it is received in the channel) Illustrative Operating System and Programming Tools Figure 1 shows an illustrative operational scenario that supports isolated Software Processes (SIPs) between the statically vepficable process and the use of programming tools that facilitate the programming of such communicative SIPs between processes statically Figure 1 shows an operating system 100 and programming tools 160 stored and / or running in a memory 110 of a computer 120 Computer 120 typically includes a variety of processor readable media (including memory 110) Such means it can be any available medium that is accessible by computer 120 and includes both volatile and non-volatile media, removable and non-removable media Computer 120 includes a computer storage device 122 (e.g., hard drive, RAID systems, etc.) which stores a group of load modules 124 and a working memory 130 (which may be part of or separated from the memory 110). The working memory 130 also includes an exchange accumulation 132, which is a buffer used to support information (such as pointers to locations in the memory). of work 130) Here, the accumulation of exchange can be called a "buffer", a "shared exchange buffer", or some equivalent to this. it includes multiple steerable memory blocks (as shown by blocks 134). Although the exchange accumulation 132 as a whole is accessible by multiple processes, each individual block is obtained by one process at a time (when that block is in use). However, the ownership of a memory block can be interchanged with other active processes. Thus, in this way, the exchange accumulation 132 provides a mechanism for SIPs for exchanging data. As illustrated, the operating system 100 comprises a module 150 process constructor. The process constructor can be part of the kernel of the operating system 100 The process constructor 150 constructs processes in a computer work memory of a dynamic group of constituent components, which typically manifests as a group of stored load modules in computer storage In the example in figure 1, the process consultant 150 builds a pro ceso 140 which is stored in the working memory 130 As illustrated herein, the process 140 is constructed of load modules 124, which are manifestations of the components of process constituents edited by the process extension components. The process 140 has a manifestation of process 142, which defines the contents of the process 140, the allowed behavior of the process, and other possible properties of the process illustrated here, the process manifestation 142 is directly associated with a process (such as process 140) whose composition describes The programming tools 160 comprise modules and data structures With this, the programming tools 160 help the person who develops the process in the creation of a static and isolated variable process with communication between process defined and restricted process The programming tools 160 facilitate this development by using strong imposition variants that are driven at the time of collection, operating time, or both. Strong vandals are discussed later in the "Verification" section. 160 programming tools provide static analysis tools to help programmers find, correct, and / or prevent communication errors between process without test and time consuming error test By increasing the effectiveness of application of h deterministic static pre-calculation analysis tools, programming tools 160 also increase the likelihood that a programmer or group of programmers will produce a program or group of programs that are free of errors related to communication between processes, and also reduces the test effort and error test required to produce such a program or group of programs The programming tools described (for example, the programming tools 160 of Figure 1) employ constructions and programming approaches that facilitate a use of developer and creation of SIPs (as described here). With the programming tools described, SIP communication can be verified statically.

Isolated Process Software In the realm of computer science and, more particularly, the technique of operating systems, the term "software process" (or more simply, "process") is well known. Applications are often composed of one or more processes. The operating system (OS) is aware of and, in fact, can handle and monitor one or more separate processes running on a computer. One or more implementations are described here to operate on an OS model that provides and / or supports an Isolated Software Process (SIP) abstraction model. SIPs encapsulate parts of a program or system and provide information for concealment, fault isolation, and strong interfaces. The SIPs are used through an OS and application software in accordance with the described implementations. With SIPs, the executable code outside the core is executed in a SIP and communicates through strongly written communication channels. A SIP is a closed environment, which does not allow data participation or dynamic code loading. SIPs differ from conventional OS processes in a number of ways. The following are examples of such forms of SIPs different from Conventional OS processes: • SIPs are closed object spaces, not address spaces. Two SIPs can not simultaneously access an object. The communications between processes transfer exclusive property of data. • SIPs are also closed source spaces. A process does not dynamically load or generate code. • SIPs do not rely on memory management hardware for isolation, so multiple SIPs can receive in a physical or virtual address space. • Communications between SIPs is through bidirectional, strongly written, higher order channels. A channel type describes its communications protocol as well as the values it transfers, and both aspects are verified. • SIPs are cheap to create and communication between SIPs incur low overhead costs. Its low costs make it practical to use SIPs as a fine grain insulation and extension mechanism. • SIPs are created and managed by the operating system, so that in the termination, the resources of a SIP can be efficiently reclaimed. • SIPs are independent execution environments, even to the extent of having different data designs, time-of-operation systems, and garbage collectors. Other secure language systems support an execution environment.

The term "software isolation process" or "SIPs" is used here for convenience. It is not intended to limit the scope of this concept. In fact, this concept can be implemented in software, hardware, firmware, or a combination thereof.

Interprocess Communication Figure 2 illustrates an illustrative interprocess communication (IPC) architecture 200 that facilitates communication between the process without unanticipated interactions between SIPs. In addition to providing interprocess communication, the illustrative IPC architecture 200 can provide interprocess communication and an operating system kernel. With the illustrative IPC architecture 200, SIPs communicate exclusively when sending messages on channels, which are a written connection for behavior, bidirectional between two processes. The messages are tagged collections of values or message blocks in an "exchange accumulation" (such as exchange accumulation 132 of Figure 1 above) that are transferred from a sending process to a receiving one. A channel writes by a contract, which specifies the format of messages and sequences of valid messages throughout the channel. As illustrated in Figure 2, the illustrative IPC architecture 200 is implemented in a "computer 202, which is configured with a memory 210 (eg, volatile, non-volatile, removable, non-removable, etc.). (OS) 212 sample stored in the memory 210 and executed on the computer 202 OS 212 has a core 220 The OS 220 core incorporates an interprocess communication (IPC) facilitator 222 The OS 220 core can build one or more processes Figure 2 shows, for example, three active processes (230, 240, and 250) running in memory 210 The IPC 222 facilitator facilitates communications between active processes (such as processes 230, 240, and 250) While Figure 2 illustrates the OS kernel 220 which implements the IPC facilitator 222, other implementations may have the IPC facilitator that is external to the OSs kernel If so, each will work in cooperation and / or coordination with the OS The memory 210 also includes an exchange accumulation 290, having multiple blocks of memory 292 Exchange accumulation 290 is accessible by multiple active processes (such as processes 230, 240, and 250) Provides a mechanism for SIPs to exchange data "Communications between processes using bidirectional message conduits" describes additional details with respect to an IPC 200 architecture, which is suitable for one or more implementations described here Exchange Accumulation Each SIP maintains its own independent accumulations and private SIPs do not share memory with each other So, when the data is passed from one SIP to another SIP, that past data does not come from a private process accumulation Instead, it comes from a separate accumulation that is used to support data which can be moved between processes. That separate accumulation is the exchange accumulation, such as the exchange accumulation 132 shown in Figure 1 or the exchange accumulation 290 shown in Figure 2. The SIPs may contain indicators in their own private accumulation. SIPs may contain pointers in public exchange accumulation In at least one described implementation, the exchange accumulation only contains pointers in the same exchange accumulation Each SIPs can support multiple pointers in the exchange accumulation However, each block of memory in the Exchange accumulation is obtained (that is, it is accessible) by, for the most part, u n SIP at any time during system execution When performing static verification, the programming tools 160 can trace the ownership of the memory blocks in the exchange accumulation because each block is obtained by, for the most part, a process in any time The fact that each block is the accumulation of exchange that is accessible by an individual process at any time also provides a guarantee of mutual exclusion Channels With the IPC 200 architecture, a channel is a bidirectional message conduit that consists exactly of two endpoints. Endpoints are sometimes called channel pairs. One channel delivers messages of less loss and in order. Also, messages typically they are retrieved in the order in which they were sent Semantically, each endpoint has a reception query, and it is sent at a final point that forms a message in the row of pair The channels are described by channel contracts In other words, the contract of each channel specifies the restrictions of communications between processes in the channel For example, the contract can specify with which other processes a process can communicate and how such communication can occur The two ends of a channel are typically not symmetric For descriptive purposes here , one endpoint is called the import end (Imp) and the other end of export (Exp) are distinguished at the level of type with types C Imp and C Exp respectively, where C is the channel contract that governs the interaction Figure 2 metaphorically illustrates channels such as electrical connectors, strings, and outputs In at least one described implementation, the channels have exactly and only two endpoints and each endpoint is obtained, mostly, by a process As illustrated, channel 260 links process 230 and OS 222 core and has only two endpoints 262 and 264 Channel 270 links process 240 and process 250 and has only two endpoints 272 and 274 Channel 280 is a newly formed channel that initially links to process 250 by itself, but still only has two endpoints 282 and 284 These channels are represented by a graphic metaphor of an "electrical cord" with exactly two "connectors" (representing end points). Rather than driving electricity, these "cords" conduct messages that are sent and received by each participant ("bidirectionally"). ") where the" cord "connects This bidirectional message that passes is illustrated by the directional covers after channel 270 The IPC 200 architecture offers a message passing IPC communication mechanism Instead of using write and read on time of some shared memory (as in some of the conventional approaches), IPC 200 architecture limits communications between processes to send and receive men The conventional OS message passing aspects are one-way mechanisms of either one sender and multiple receivers or multiple senders and one receiver. Unlike those conventional approaches, the IPC 200 architecture channels are two-way mechanisms with exactly two extreme points and maximum two participants This is illustrated by channel 260 and channel 270 in Figure 2 Channel 260 links process 230 and OS 220 core and only those two. Channel 270 links process 240 and process 250 and only those two. As illustrated in Figure 2, each bidirectional IPC channel has exactly two endpoints of channel Each channel end point is obtained, for the most part, by one process at a time. For example, a channel endpoint is obtained by one process and the other channel endpoint is obtained by another process or is obtained by the core of the operating system Endpoints can be transferred into channels By doing so, the ownership of those endpoints is transferred The IPC 222 facilitator guarantees that each message and each message encapsulation are mostly obtained by a process in Any instant This can be done by using a channel-level abstraction for each channel. Additionally, at the level of channel abstraction, a message resides in the accessible memory of, at most, a process in any instant From the perspective of communication processes, the state contained within or accessible from a message is never shared. In at least one described implementation, a message is accessible by the message creator only until it is sent in at least one described implementation, a message is accessible by the message receiver only after it is received Property The isolation of memory from endpoints other than data transferred in channels is guaranteed by tracking the collection time of all blocks in the exchange accumulation. In particular, static reviews drive access to those resources that occurs at program points where the resource is obtained and those methods do not escape ownership of the resources. Tracked resources have a strict ownership model. Each resource is obtained mostly by a process at any point in time. For example, if an endpoint is sent in a message from the sequence T1 to the sequence T2, then the property of the endpoint changes: from T1 to the message and then to T2, with the reception of the message. In conventional aspects, a process makes a data copy and passes that data. Consequently, these data are now obtained through multiple processes. The process that sent the data can still act on your copy of the data. With at least one described implementation, the ownership of the data is linked to specific SIPs. Ownership of the data passes along with the data that is passed. Therefore, sending SIP can not act on the data once it passes since it no longer has access to this and does not make a copy of this. In one or more implementations described here, the data is obtained by a SIP and its property passes along with the data once it is sent on a channel. Similarly, each endpoint of a channel is obtained only by a SIP The ownership of an endpoint happens with the transfer from one endpoint to another SIP Once it is sent, a sending SIP no longer has access to the endpoint of the channel that just sent it. property (of endpoints and data) is realized through an exchange accumulation, such as the exchange accumulation 132 shown in Figure 1 or the exchange accumulation 290 shown in Figure 2 More specifically, a memory block in the exchange accumulation contains a pointer (to the data memory location in question or an endpoint in question) When exchanged with another process through a channel, the sending process passes along the pointer to the memory block in the accumulation of exchange to the reception process In this way, the sending process effectively passes along the data in question to the reception process, but does so without making or retaining a copy for itself In addition, the sending process effectively passes the ownership of the endpoint in question to the receiving process, without retaining property. The transfer of ownership can also be described as the sender of the message that passes ownership by storing a flag to the message at the receiver endpoint, at a location determined by the current status of the message exchange protocol These exchanges where data is not copied can called a "zero copy" approach By using such an approach, disk buffers and network packets can be transferred across multiple channels, through a protocol stack and in an application process, without copying or retention of the shipping data Channel Contracts Channel contracts are used for implementations described here in order to facilitate the process isolation architecture. Channel contracts (and other aspects of communication between processes) are also described in "Communications between processes that use message conduits. bidirectional "Here is an illustrative contract that describes the simple interaction in a C1 contract channel. { in Message Request (int x) requires x > 0, out of message Answer (? Nt y), out of message Error () status Start request? - > (Reply! Or Error ') - > Start, } In this example, contract C1 declares three messages Request, Response, and Error Each message declaration specifies the types of arguments contained in the message By For example, Request and Response both contain an individual integer value, while Error does not carry any of the values. Additionally, each message can specify Spec # that requires clauses that additionally restrict the arguments. Messages can also be labeled with an address. point of view exporter Thus, in the message, Request is a message that can be sent by the importer to the exporter, while Response and Error were sent from the exporter to the importer Without a qualifier, the messages can travel in both directions. message statements, a contract specifies the permissible message interactions through a state machine driven by sending and receiving actions The first declared state is considered the initial state of the interaction The illustrative contract C1 declares an individual state called Start After of the status name, the action Request d indicates that in the Start state, the export side of the channel wants to receive a Request message following the construction (Response 'or Error') Specifies that the exporter sends d) Any Response or Error message The last part (? ) specifies that the interaction then continues to the Start state, thereby turning on the promotional infinitum. A slightly more involved example is a portion of the contract for the network stack Public Contract TcpContratodeConexión. { // Requests in Message Connection (uint dstIP, ucorto dstPuerto); out of message Ready (); // Initial status Start status: Ready! - > State Ready; State Ready status: one. { Connection? - > Connection Result; Join Local Endpoint? - > Union Result; Close? - > Closed; } // Join a local endpoint State JoinResult: one. { TO ACCEPT! - > Limit; Final Point Invalid! - > State Ready; } In message Listen () State Limit: one. { Hear? - > ListenResult; Connect? - > ConnectResult; Close? - > Closed; } The protocol specification is a contract that serves several purposes. It can help detect programming errors, either at run time or through a static analysis tool The run time check drives a contract state machine in response to messages exchanged on a channel and observes erroneous transitions By itself, the time verification technique operation detects errors in a program execution, but can not detect "vitality" errors such as a non-termination Vitality properties are properties of the form "something good happens eventually", for example, "eventually the program sends a message "Static program analysis can provide a stronger guarantee that processes are corrected and are free of stagnation in all program executions., static analysis is not limited to verifying an execution while it happens. For example, you can rely on the examination of instructions in the process in order to determine if the process will eventually do something or not. There are fundamental results in the logic that say that this is not true. it will always work, but it can work well enough in many cases An implementation uses a combination of verification of operation time and static verification All messages in a channel are checked against the channel contract, which detects correction, but not problems of vitality The implementation described here has a static reviewer that verifies security properties. In addition, a compiler uses a contract to determine the maximum number of messages a channel can support, which allows the collector to statically distribute buffers at the channel endpoints. Staticly distributed buffers improve communication performance.

Endpoints The channels are manifested as a pair of endpoints that represent the import and export sides of the channel. Each end point has a type that specifies to which contract the channel adheres. The endpoint types are implicitly declared within each contract. A contract C1 is represented as a class, and the endpoint types are types nested within that class as follows: • C1. Imp - Type of import endpoints of channels with C1 contract. • C1. Exp - Type of export endpoints of channels with contract C1.

Shipping / Receiving Methods Each contract class contains methods to send and receive the messages declared in the contract. The example provides the following methods: C1. Imp. { Empty Send Request (int x); Empty Recall (outside int and); Empty RecvErrorQ; } d.Exp. { Empty RecvRequest (outside int x) Empty SendResponse (int y); Empty Send Error (); } The semantics of the Send methods are that they are sent to the message asynchronously. The reception methods are blocked until the given message arrives. If a different message arrives first, an error occurs. Such errors should never occur if the program passes the contract verification review. Unless a recipient with whom exactly what message he requires later, these methods are not appropriate.

Methodological Implementations Figure 3 shows methods 300 and 400 to facilitate communication between the effective process for statically verifiable SIPs. These methods 300 and 400 are performed by one or more of the various components as illustrated in Figures 1 and 2. In addition, these methods 300 and 400 may be performed in software, hardware, firmware, or a combination thereof. In block 302 of Figure 3, the operating system (OS) provides the execution of one or more software isolation processes (SIPs) in an operating system environment of In block 304, the OS associates particular data group property with a first SIP This data group can be a block of memory in an exchange accumulation, such as the exchange accumulation 132 shown in Figure 1 or the accumulation exchange 290 shown in Figure 2 This group of data can be a message This data group can include data or one or more pointers to memory locations that contain data Also, this group of data can include one or more pointers to endpoints In block 306, the OS sends the particular data group from the first SIP to a second SIP. The sending here may consist of providing a pointer to the data group (in the exchange accumulation) to the second SIP. Alternatively, the sending may be consist of writing a message to the endpoint of a channel connected to the second SIP In block 308, the OS transfers particular data group property of the first SIP to the second SIP When a message is sent on a channel, the property passes from the sending SIP to the receiving SIP The sending SIP no longer retains a reference to the message In fact, the sending SIP no longer has access to the message sent During the 306 transfer 308, no copy of the information sent is retained In fact, no copy of the sent information is created Since only the pointer to the data group (or more precisely, a pointer to the block of memory that stores the data or pointer) is passed, no copy is created or sent This non-variant property is driven by the programming tools and the operating system (such as programming tools 160 and OS 100) This non-vanishing property serves at least for three purposes the first is to prevent participation between processes The second is to facilitate static program analysis by eliminating flag that provides message statistics The third is to allow implementation flexibility by providing message passing semantics that can be implemented when copying or by passing the bookmark As illustrated in Figure 4, in 402, the operating system provides for the execution of one or more software isolation processes (SIPs) in a computer operating system environment In block 404, the OS associates property of a particular endpoint of a communication channel between particular process with a first SIP This data group can be a block of memory in an exchange accumulation, such as the exchange accumulation 132 shown in Figure 1 or the exchange accumulation 290 shown in Figure 2 This data group can be a message This group of data can include one or more pointers The data group can include one or more pointers to memory locations that contain one or more pointers Also, this group of data can include one or more pointers pointers to channel end points. In block 406, the OS sends the particular endpoint of the communications channel from the particular process of the first SIP to a second SIP. The submission here may consist of providing a point to the particular end point (in the exchange accumulation) to the second SIP. Alternatively, the sending may consist of writing a message to the endpoint of a channel connected to the second SIP. In block 408, the OS transfers ownership of the particular endpoint of the communication channel between the particular process of the first SIP to the second SIP. When the endpoint property passes from the sending SIP to the receiving SIP, the sending SIP no longer retains a reference to the message. In fact, the sending SIP no longer has access to the data sent. In addition, this transfer of endpoint property occurs without creating and passing along a "copy". Since only the pointer to the endpoint (or a pointer to the memory block that stores the pointer to the endpoint) is passed, no copy is created or sent.

Verification The programming tools 160 can verify the programming of one or more SIP. The programming tools 160 verify that executed code that is of secure type and imposition of using the strong non-variants by the compiler and in operating time. Such strong non-variants are included (by way of example and not limitation): • Each block is the exchange accumulation that has a maximum obtained sequence (ie, processes) at any point in time. • The blocks in the exchange accumulation are only accessed by the owner of that block. That way no access is released after a block or a transfer of ownership. • The imposition of channel contracts that define and restrict communication between processes (for example, the sequence of messages observed in a channel correspond to the channel contract).

Methodological Implementation of Verification Figure 5 shows the method 500 for verification of isolated processes. This method 500 is performed by one or more several components as illustrated in Figures 1 and 2. In addition, this method 500 can be performed in software, hardware, firmware, or a combination thereof. In block 502 of Figure 5, collect executable code for one or more software isolation processes (SIPs) in a computer operating system environment that supports SIPs. In block 504, during the collection time, the programming tools 160 confirm each block of memory in the exchange accumulation that has a property process at a maximum in any point in time This means that only one SIP will have any particular memory block at any time In block 506, during the collection time, the programming tools 160 confirm that each block of memory in the exchange accumulation is only accessed by its owner with rights (for example, SIP) In block 508, during the collection time, the programming tools 160 confirm that the terms of the contracts are followed For example, the tools confirm that the message sequence defined in the control is observed. The programming tools 160 can report the results of such confirmations to a user, a program module, and / or the operating system. You can perform your verification during collection. In addition, you can also verify these pr opiedades in the generated intermediate language code In addition, programming tools 160 can verify a resulting form of the written assembly language even again Conclusion The techniques, described here, can be implemented in many ways, including (but not limited to) program modules, general purpose and special computing systems, network and computer servers, dedicated electronics and hardware, firmware, as part of one or more computer networks, or a combination thereof One or more implementations described herein can be implemented through many well-known computer systems, environments, and / or configurations that are suitable for use including, but not limited to, personal computers (PCS), server computers, mobile or portable devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, cordless telephones and equipment, general and special purpose devices, application-specific integrated circuits (ASICs), network PCs, thin clients, thick clients, cable TV boxes, minicomputers, macrocomputers, distributed computing environments that include any of the systems or prior devices, and the like Although one or more implementations described above were described in language specific to structural features and / or methodological steps, it should be understood that other implementations may be practiced without the specific illustrative features or steps described herein. More than that, the specific illustrative features and steps are described as preferred forms of one or more implementations. cases, well-known features could be omitted or simplified to clarify the description of the illustrative implementations. ease of understanding, certain method steps are outlined as separate steps; however, these separately outlined steps should not be constructed as necessarily dependent on order in their performance.

Claims (10)

1. - One or more processor-readable media having executable instructions per processor which, when executed by a processor, perform a method comprising: associating property of a particular data group with a first process (240); send the particular data group from the first process (240) to a second process (250); transferring ownership of the particular data group from the first process (240) to the second process (250), wherein the first process (240) no longer has access to the particular data group after the transfer.

2.- One or more means according to claim 1, wherein the data group includes a message.

3. One or more means according to claim 1, wherein the data group includes an endpoint of one or more communication between processes.

4. One or more means according to claim 1, wherein the property transfer occurs through one or more communication channels between process that are connected to the first process (240) and second process (250).

5. One or more means according to claim 1, wherein both the sending and transfer are performed without memory distribution.

6. - One or more means according to claim 1, wherein the data group is stored in a steerable location in a distributable memory, the distributed memory having multiple steerable locations, each location being accessible by either the first or second processes (240 and 250), but not both simultaneously.

7.- One or more processor-readable media having executable instructions per processor that, when executed by a processor, perform a method comprising: providing execution of one or more isolated software processes in a computer operating system environment , where ownership transfer occurs through one or more communication channels between processes, where each communication channel between processes consists of two or more endpoints; sending a particular data group from the first process (240) to the second process (250) through the communication channel between processes; transfer property of the particular data group obtained by the first isolated software process (240) of the first isolated software process (240) to the second isolated software process (250).

8. - One or more means according to claim 7, wherein the first software process (240) no longer has access to the particular data group after the transfer. 9.- One or more means according to claim 7, in where the particular data group is stored in a steerable location in a buffer, the buffer having multiple steerable locations, each location being accessible by either the first and the second isolated software processes (240 and 250), but not both simultaneously . 10.- One or more processor-readable media having executable instructions per processor that, when executed by a processor, perform a method comprising: obtaining one or more isolated software processes in a computer operating system environment, wherein two or more isolated software processes obtained are formatted to be executable in the computer operating system environment; confirming that no memory block in a shared exchange accumulation (290) is simultaneously accessible by more than one isolated software process, wherein such access will occur while two or more isolated software processes are executed, the shared exchange accumulation (290) ) having one or more memory blocks and one or more of one or more memory blocks are simultaneously accessible to two or more isolated software processes when the processes are executed.