Inter-process communication (IPC) is the central component of the OKL4 system design. OKL4 facilitates both communication between threads residing in different address space and threads within the same address space.
(IPC는 OKL4 시스템 디자인의 중심 컴포넌트이다.-핵심이라는 말.. OKL4는 다른 주소공간에 존재하는 쓰레드들 간의 통신과 같은 주소공간의 쓰레드간의 통신, 양쪽 모두 쉽게 한다.)
In OKL4, all communication is synchronous and unbuffered with the exception of the restricted form of asynchronous communication.
(OKL4에서 모든 통신은 제한된 비동기 통신의 형태를 제외하고는 비동기적이고 언버퍼드이다.)
* with the exception of[that ...] :...을 제외하고는, ... 이외는
IPC consists of the exchange of short messages between two threads in the system. Each message consists of a message tag and an optional list of message data. The messages are exchanged directly through the MessageData registers. This exchange is unbuffered, the microkernel copies the content of the MessageData registers of the sender directly to the corresponding registers of the receiver. This is the key to the high performance of the OKL4 microkernel.
(IPC는 시스템상의 두 쓰레드간간 짧은 메세지의 교환으로 구성된다. 각 메세지는 메세지 태그와 옵션의(선택가능한) 메세지 데이터 리스트로 구성된다. 메세지는 MessageData 레지스터를 통해서 직접적으로 교환되어진다. 이 교환은 버퍼링되지 않는다. 마이크로커널은 전송자의 MessageData 레지스터의 내용을 직접적으로 수신의 해당 레지스터로 복사한다. 이것은 OKL4의 높은 실행력의 핵심이다.)
To ensure that the integrity of the receiving thread is not compromised, messages are exchanged synchronously. That is, the microkernel does not deliver the message until the recipient is ready to receive the supplied data, often suspending execution of the sender until the message is transmitted.
(수신하는 쓰레드의 무결성을 보장하는 것은 타협되지 않는다. 메시지는 비동기적으로 교환되어 진다. 마이크로커널은 수납자(메세지를 받는 쓰레드)가 공급되는 데이터를 받을 준비가 될때까지 메세지를 전달하지 않는다. 이것은 종종 메세지가 전송이 될 때까지 송신자의 지연되는 실행이 된다.)
OKL4 defines two fundamental IPC operations.
(OKL4는 아래 2개의 기본적인(중요한) IPC 동작을 정의한다.)
a. A send operation delivers messages from the calling thread to a destination thread.
(전송동작은 호출하는 쓰레드에서 목적지 쓰레드까지 메세지를 전달한다.)
b. A receive operation requests a message from another thread.
(수신동작은 다른 쓰레드로부터 메세지를 요청한다.)
These two operations are associated with user requested policy or whether to perform the operation blocking or non-blocking. If an IPC operation is blocking, it will cause the IPC, and thus the thread, to block until a corresponding IPC operation has been performed by the target thread. A non-blocking IPC operation fails immediately if the target thread is not ready to participate in the message exchange at the time of request. Additionally, a special encoding of the send operation known as a notify operation may be used to send asynchronous notification events.
(이 두 동작은 사용자 요청 정책 또는 블록킹되는 연산이거나 넌블록킹되는 연산을 수행하는 것과 결합된다. IPC 연산이 블록킹이면 IPC, 따라서 쓰레드가 해당하는 IPC연산이 대상 쓰레드에 의해서 모두 수행될때까지 블록된다. 만약 대상 쓰레드가 요청한 시간에 메세지 교환에 참여할 준비가 되어 있지 않다면 넌블럭킹 IPC연산은 즉각적으로 실패한다. 추가적으로, 특별한 전송연산의 encoding은 비동기적인 통지 이벤트를 전송하기 위해서 사용되어질 수 있는 notify연산으로 알려져 있다. )
OKL4 supports the asynchronous delivery of a restricted form of messages of a set of FLAG objects.
(OKL4는 FLAG 객체 집합의 메세지의 제한된 형태의 비동기적인 전달을 지원한다.)
Additionally, a single invocation of the Ipc system call may be used to perform a combination of IPC operations. Such composite operations are executed atomically by the microkernel. The invoking thread remains blocked until all operations requested by the system call are completed or aborted. Specifically, a single invocation of the Ipc system call may be used to perform either a single IPC operation or a pair of IPC operations. In the later case, the first operation must be a send, and the second must a receive operation.
(추가적으로, IPC 시스템콜의 단독 발동(청원)은 IPC 연산들의 콤비네이션(결합, 연속된 동작)을 수행하는데 사용될 수도 있다. 이런 합성 연산들은 커널에 의해서 자동적으로 실행되어진다. 호출하는 쓰레드는 시스템콜에 의해서 요청된 모든 연산이 완료되거나 중지될 때까지 블럭된 채로 남는다. 특별히 IPC 시스템콜의 단독 발동(청원)은 단돈 IPC동작 또는 IPC동작의 쌍중 하나를 수행하는데 사용되어질 수 있다. 마지막 경우에, 첫번째 동작은 반드시 전송이 되어야 하고, 두번 연산은 받드시 수신동작이 되어야 한다.)
The recipient of an IPC message is supplied with a reply cap to the thread that has issued the send or reply operation. This capability allows the recipient to reply to the message as long as the sender has also specified a receive operation to the same recipient thread in the IPC operation.
(IPC메세지의 수신자는 전송또는 응답 동작을 발행했던쓰레드를 향한 reply cap과 함께 제공된다. 이 capability는 전송자 또한 IPC동작안의 같은 수신 쓰레드를 향한 수신동작을 명시하는한 수신자에게 메세지에 응답하는 것을 허용한다.)
1. Message Tags.
Each IPC Message begins with a message tag stored in the MessageData0 register. Message tags are represented by the MessageTag Type.
(각 IPC 메세지는 MessageData0 register에 저장된 Message tag와 함께 시작된다. Message tag들은 MessageTag Type으로 표현되어진다.)
Each tag consists of a message label, a Untyped field specifying the number of data words in the corresponding message, and a set of four message flags S, R, N and M. These flags are used to identify the requested IPC operations and are not delivered to the target thread.
(각 Tag는 Message label, 해당 메세지안의 데이터 워드들의 수가 명시되는 untyped field, 그리고 S, R, N, M 4개의 메세지 플래그 집합으로 구성한다. 이 플래그들은 요청된 IPC 동작을 확인(식별)하는데 사용되고 대상 쓰레드에게는 전달되지는 않는다.)
Upon the delivery of the message, the microkernel replaces the these flags of the message tag with an error indicator and a performance-related remote IPC flag. All other field of the message tag are always delivered unchanged to the recipient of the message.
(메세지가 전달에, 마이크로커널은 메세지tag의 이 플래그들을 에러 인디케이터와 수행능력에 관여된 리모터 IPC flag로 대체한다. 메세지 tag의 다른 field는 항상 변경이 되지 않고 메세지 수신자에게 전달되어진다.)
2. Message Data
Each message contains at least 16bits(or 48bits on 64bit architectures) of user interpreted data represented by the message label stored in the Label field of its message tag. The message label is not interpreted or modified by the microkernel and is delivered directly to the recipient. The user is free is use this field for any purpose, however it is commonly used for specifying the message type.
(각 메세지는 적어도 16비트(또는 64비트 아키텍처에서는 48비트)의 메세지 Tag의 Label 필드에 저장된 메세지 label로 표현된 사용자 해석 데이터가 포함한다. 메세지 Label은 커널에 의해서 해석되거나 수정되지 않고 직접적으로 수신자에게 전달된다. 사용자는 이 필드가 일반적으로 메세지 타입을 명세하기 위해 사용할지라도 어떤 목적으로 사용하던지 자유이다.)
The size of the message label means it is not generally useful for sending information. Therefore, OKL4 implementations allow the user to attach up to 63 user-interpreted words of information to a single IPC message. Note that individual OKL4 implementations may reduce the maximum message size by setting the MaxMessageData system parameter to a value less than 63.
(메세지 라벨의 크기는 일반적으로 전달하는 정보로 사용하기에는 유용하지 않다는 것을 나타낸다. OKL4 구현은 사용자에게 단일 IPC 메세지에 63 사용자 해석 words 정보를 붙이는 것을 허용한다. 개인적인 OKL4 구현은 MaxMessageData 시스템 파라메터를 63보다 작은 값으로 설정함으로써 최대 메세지 크기를 줄일지도 모른다.)
The number of data words attached to a particular message is specified in the Untyped field of the message tag. As with the message label, the microkernel does not interpret or modify the data words. The sender of a message supplies the values of any required data words in its MessageData1 to MessageDatak registers, where k is the value of the Untyped field in the corresponding message tag. Upon successful delivery of a message, these registers are copied to the corresponding registers of the target thread.
(특정 메세지에 붙은 데이터 words의 수는 메세지 Tag의 Untyped field안에 명시된다. 메세지 Label과 마찬가지로, 마이크로커널은 데이터 word를 해석하거나 수정하지 않는다. 메세지의 전송자는 MessageData1에서 MessageDatak 레지스터안의 어떠한 요구된 데이터 word의 값을 제공한다. K는 해당 메세지 Tag의 Untyped field의 값이다. 메세지의 성공적인 전달에서 이 레지스터들은 대상 쓰레드의 해당 레지스터로 복사된다.)
3. Sending IPC Messages
When a thread requests an IPC send operation, the microkernel looks up the destination thread, by checking the corresponding capability in the sender's capability space. If capability is not found, the operation is immediately aborted with an appropriate error without performing any receive operations requested. Otherwise, the behavior depends on the state of the target thread.
(쓰레드가 IPC 전송 동작을 요청할 때, 마이크로커널은 전송 쓰레드의 capability space안의 해당 capability를 검사함으로써 목적지 쓰레드를 찾는다. 만약 capability를 찾지 못한다면, 동작은 즉각적으로 적합한 에러와 함께 어떠한 요청된 수신 동작의 수행없이 중단된다. 만약 그렇지 않다면, 작동은 목적 쓰레드의 상태에 달려있다.)
a. If the target thread is waiting to receive a message from the sender, the message is delivered immediately to the recipient and the microkernel proceeds with any IPC receive operations requested by the sender.
(만약 대상 쓰레드가 전송자로부터 메세지를 수신하기 위해서 대기중이라면, 메세지는 즉각적으로 수신자에게 전달되고, 마이크로커널은 전송자에 의해 요청된 어떤 IPC 수신동작을 시작한다.)
* proceed with : ~하기 시작하다.
b. Alternatively, the microkernel checks whether the requested send operation was requested as blocking or non-blocking.
(수신 쓰레드가 waiting이 아니라면, 마이크로커널은 요청된 전송 동작이 블록킹으로 요청된지, 넌블로킹으로 요청되었는지 검사한다.)
- If a blocking send operation is requested, the microkernel marks the sender as polling and enqueues it in the IPC queue of the recipient. The sender will remain blocked until the recipient issues an appropriate receive operation, or until the IPC operation is cancelled using the ExchangeRegisters system call.
(만약에 블록킹 전송 동작이 요청되었다면, 마이크로커널은 폴링으로 전송자를 표시하고, 수신자의 IPC큐에 넣는다. 전송자는 수신자가 적합한 수신 동작을 발행하거나 IPC 동작이 ExchangeRegisters 시스템 콜을 사용하여 취소될때까지 멈춘 채로 남아있을 것 이다.)
- If a non-blocking send operation is requested, the operation is immediately aborted with an appropriate error message without performing any IPC receive operations requested by the sender.
(만약 넌블럭킹 전송 동작이 요청되었다면, 동작은 전송자에 의해서 요청된 어떤한 IPC 수신동작들 없이 적합한 에러 메세지와 함께 즉각적으로 멈춘다.)
A common term for a non-blocking send is an IPC reply operation.
(넌블럭킹 전송의 일반적인 용어는 IPC 응답 동작이다.)
4. Sending Asynchronous Notification Messages
The IPC notify operation provides a restricted form of asynchronous communication between threads and consists of the delivery of a set of notify flags to the recipient without the need for the recipient to invoke an explicit IPC receive. The notify operation is always non-blocking and delivers only a single word of data representing the desired notify flags to the recipient irrespective of the number of data words specified by the sender in the corresponding message tag.
(IPC 통지동작은 쓰레드들간의 제한된 비동기 통신의 형태를 제공하고 수신자의 명백한 IPC 수신 호출의 필요없이 지 flags 집합의 전달로 되어있다. 통지동작은 항상 넌블럭킹이고 단지 요구되는 통지 flag를 표현하는 데이터를 해당하는 메세지 tag에 전송자에 의해서 명시된 data word의 수와 상관없이 하나만 전달한다. )
* irrespective of ~ : ~와 상관없이.
When a thread requests an IPC notify operation, the microkernel looks up the destination thread, by checking the corresponding capability in the sender’s capability space. If the capability is not found, the operation is immediately aborted with an appropriate error message. The operation is also aborted if the Notify flag is cleared in the Acceptor register of the recipient. Otherwise, the notify flags are immediately delivered to the
recipient by updating its NotifyFlags. Notify flags can only set flags in the destination, a cleared flag in the message has no effect on the current value of the corresponding flag in the NotifyFlags register of the recipient
(쓰레드가 IPC 통지 동작을 요청할 때, 마이크로커널은 목적지 쓰레드를 전송자의 capability 공간안의 해당하는 capability를 검사함으로써 찾는다. 만약 capability를 찾지 못하면, 동작은 즉각 적합한 에러 메세지와 함께 중단된다. Notify flag가 수신자의 Acceptor 레지스터의 Notify flags가 클리어되어있다면 동작은 역시 중단된다. Notify flags는 단지 목적지안 플래그들을 설정할 수 있다. 메세지의 클리어된 플래그는 수신의 NotifyFlags 레지스트의 해당 플래그의 현재값이 효과가 없다.)
The microkernel then checks whether the recipient is waiting for an IPC from the sender. If so, it compares the updated value of the recipient’s NotifyFlags with the value of its NotifyMask register. If the intersection of these two registers is non-empty, the microkernel delivers an asynchronous notification message to the recipient.
(그리고나서, 마이크로커널은 수신자가 전송자로부터 IPC를 기다리는지 아닌지를 검사한다. 만약 그렇다면, 수신자의 NotifyFlags들의 갱신된 값을 NotifyMask register의 값과 비교한다. 만약 두 레지스터의 교차가 있다면, 마이크로커널은 비동기적인 통지 메세지를 수신자에게 보낸다.)
When an asynchronous notification message is delivered, the microkernel delivers the set of flags from the intersection of the recipient’s NotifyFlags ands NotifyMask registers in the message. It subsequently clears these bits from the recipient’s NotifyFlags register. These two operations are done atomically. Furthermore, the microkernel clears the Untyped, Label and P fields in the message tag and delivers the supplied message to the recipient as if it was performing a normal send operation. The microkernel indicates the origin of message as coming from NILTHREAD. The microkernel then proceeds with any IPC receive operations requested by the sender.
(비동기적인 통지메세지가 전달되었을 때, 마이크로커널은 수신자의 메세지의 NotifyFlags와 NotifyMask레지스터의 교차점의 플래그 집합을 전달한다. 그 다음에 수신자의 NotifyFlags 레지스터의 이 비트들(the intersection)들을 클리어한다. 이 두 동작은 자동으로 완료된다. 게다가, 마이크로커널은 메세지 태그의 Untyped, Label, 그리고 P filed를 클리어하고, 마치 일반적인 전송 동작인것 처럼 공급되는 메세지를 수신자에게 전달한다. 마이크로커널은 메세지의 출처를 NILTHREAD로부터 발생한 것 처럼 나타낸다. 그리고나서, 마이크로커널은 전송자로부터 요청된 어떤 IPC 수신 동작을 진행한다.)
5. Receiving IPC Messages
The IPC receive operation is used by a thread to request a message from another threads in the system. Besides blocking and non-blocking variants, the OKL4 microkernel defines two variants of the receive operation, closed and open. In a closed receive operation, a thread (recipient) requests a message from a specific OKL4 thread. The caller must have a capability to the recipient in its capability space.
(IPC 수신 동작은 시스템상의 다른 쓰레드들로부터 메세지를 요청하기 위해서 쓰레드에의해서 사용되어진다. 블럭킹과 넌블럭킹 종류와 나란히, OKL4 마이크로커널은 수신동작의 두자지 종류 closed와 open를 정의한다. closed 수신 동작에서는 쓰레드(수신자)는 명시적인 OKL4 쓰레드로부터 메세지를 요청한다. 호출자는 반드시 capability space에 수신자에 대한 capability를 가지고 있어야한다.)
In an open receive operation, the recipient requests a message from any member of a particular class of threads. The list of recognized classes of threads is specified in the description of the Ipc system call. the behaviour of the microkernel upon recipient of the IPC recieve operation depends on th contents of its IPC queue.
(open 수신 동작에서는 수신자는 쓰레드들의 특정 클래스의 어떤 멤버에게 메세지를 요청한다. 인정된 쓰레드들의 클래스들이 리스트는 Ipc 시스템 콜의 description에 명세되어진다. IPC 수신동작의 수신자상의 마이크로커널의 행동은 IPC큐의 내용들에 따라 달라진다.)
a. If the IPC queue contains the specific thread, or a thread from the class of threads specified by the recipient, the first such thread is removed from the queue and the message is delivered immediately to the recipient. The sender is added back to the system scheduling queue. The microkernel will complete any pending receive operations requested by the sender once it is allocated processing time by the thread selection algorithm
(IPC큐가 명시된 쓰레드나 수신자에 의해서 명시된 쓰레드 클래스중 하나의 쓰레드를 포함하면, 이런 첫번째 쓰레드는 큐에서 제거되고 메세지는 즉각적으로 수신자에게 전송된다. 전송자는 시스템 스케줄링 큐에 다시 추가된다. 마이크로커널은 전송자에 의해서 요청된 어떤 지연된 수신 동작을 완료할 것이다.)
b. Alternatively, the microkernel checks whether the requested receive operation was requested as blocking or non-blocking.
(다른 하나는(즉, IPC큐에 쓰레드가 없는경우...), 마이크로커널은 요청된 수신 동작이 블럭킹으로 요청된 것인지 아니면 넌블럭킹으로 요청된 것인지를 검사한다.)
- If the recipient requests a blocking receive operation, the microkernel marks it as waiting to receive and will remain blocked until the sender issues an appropriate IPC send operation, or until the IPC operation is cancelled using the ExchangeRegisters system call
(만약 수신자가 블럭킹 수신 동작으로 요청을 했다면, 마이크로 커널은 수신하기 위해서 대기로 표시하고, 전송자가 적합한 IPC 전송 동작을 호출하거나 IPC 동작이 취소될 때까지 블럭상태로 남아있을 것이다. --' 대충.. 대충..)
- If the recipient requests a non-blocking receive operation, the receive operation is aborted immediately with an appropriate error message.
(만약 수신자가 넌블럭킹 수신 동작을 요청했다면, 수신동작은 적합한 에러메세지와 함께 즉각적으로 멈춘다.)
On successful reception of a message, the microkernel provides the recipient with a replay cap to the sender. If the sender specified a receive operation specifying the recipient, the recipient may use this capability to replay to the thread.
(성공적인 메세지 수신에서 마이크로커널은 전송자의 replay cap을 수신자에게 제공한다. 만약 전송자가 수신자를 명시하는 수신 동작을 명시했다면, 수신자는 이 capability(replay cap)를 쓰레드에게 응답하는데 사용할지 모른다.)
A common term for a blocking receive operation is an IPC wait operation which may also be used with the open or closed prefix.
(일반적인 블럭킹 수신 동작의 용어는 open또는 closed 접두사와 함게 사용되어질지 모르는 IPC 대기 동작이다.)
댓글 없음:
댓글 쓰기