KR100421797B1 - 내부실행스레드관리시스템및그의방법 - Google Patents

내부실행스레드관리시스템및그의방법 Download PDF

Info

Publication number
KR100421797B1
KR100421797B1 KR1019970703853A KR19970703853A KR100421797B1 KR 100421797 B1 KR100421797 B1 KR 100421797B1 KR 1019970703853 A KR1019970703853 A KR 1019970703853A KR 19970703853 A KR19970703853 A KR 19970703853A KR 100421797 B1 KR100421797 B1 KR 100421797B1
Authority
KR
South Korea
Prior art keywords
event
entity
list
thread
entities
Prior art date
Application number
KR1019970703853A
Other languages
English (en)
Other versions
KR987000610A (ko
Inventor
울프 미카엘
Original Assignee
텔레폰아크티에볼라게트 엘엠 에릭슨
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 텔레폰아크티에볼라게트 엘엠 에릭슨 filed Critical 텔레폰아크티에볼라게트 엘엠 에릭슨
Publication of KR987000610A publication Critical patent/KR987000610A/ko
Application granted granted Critical
Publication of KR100421797B1 publication Critical patent/KR100421797B1/ko

Links

Images

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/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)
  • Information Transfer Between Computers (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Plural Heterocyclic Compounds (AREA)
  • Jib Cranes (AREA)
  • Multi Processors (AREA)
  • Alarm Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

프로세스에서 내부 실행 스레드를 관리하는 시스템에 있어서, 실행 스레드는 프로세스 내부 이벤트 메시지에 의해 구동된다. 이러한 메시지는 이벤트 발생 함수의 분배 카테고리를 토대로 이벤트 수신 스레드(1208 내지 1212)에 분배되고, 그러한 내부 메시지에 관심이 있어 그의 발생의 모니터링을 유발시키는 이벤트 수신 스레드에 대해서만 수행된다. 각 분배 카테고리에는, 다수의 이벤트 수신 스레드, 어떤 이벤트 수신 스레드로의 하나의 이벤트 발생 함수에 대한 하나 이상의 모니터링을 표시하는 다수의 제 1 엔티티(1228 내지 1238), 분배 카테고리의 이벤트 발생함수에 대한 모니터링을 표시하는 다수의 제 2 엔티티(1216 내지 1220), 및 분배 카고리를 모니터한 모든 이벤트 수신 스레드의 트랙을 유지하는 제 3 엔티티(1214)가 관련되어 있다.

Description

내부 실행 스레드 관리 시스템 및 그의 방법
미국 특허 제 5,421,013 호에서, 애플리케이션은 에이전트 클래스의 인스턴스(instances)를 수집한 것이고, 각 에이전트 클래스는 자신의 메시지 디스패칭(dispatching) 함수를 갖는다. 멀티스레딩은 애플리케이션 프로그래밍 인터페이스에 의해 제공되는 데, 이러한 인터페이스는 개별 에이전트에 대한 시간을 비선점하여 할당하는 마스터 디스패처 프로세스를 포함한다.
미국 특허 제 5,355,488 호에서, 애플리케이션 프로그램 인터페이스에 의해 한 번 설정된 태스크(task)가 휴지(idle) 상태로 유지되게 하는 방법이 태스크 후에 완성된다. 설정된 태스크는 풀(pool)에서 유지된다. 태스크 관리자는, 애플리케이션 작업 요청에 응답하여, 태스크 요청에 대응하는 휴지 태스크를 위한 풀을 초기에 탐색한다. 풀내에 대응하는 휴지 태스크가 있다면, 제어는 실행을 위한 애플리케이션 코드로 통과한다.
미국 특허 제 5,345,588 호는, 하나 이상의 스레드의 컨텍스트에서 실행되는 절차에 의해 요구되는 각 초기화 데이터 세트의 전용 카피(private copy)를 멀티-스레딩 디지털 데이터 처리 환경을 실행하는 각 스레드에 제공하는 방법을 개시한다.
미국 특허 제 5,319,782 호는, 제 1 다중 태스크 동작 시스템으로부터의 태스크의 디스패칭(dispatching)을 제 2 다중 태스크 동작 시스템으로부터 기회적으로 디스패치된 함수 호출의 스레드와 동기화하는 것을 개시한다. 이러한 제 2 동작 시스템은 호출 가능한 자원의 세트를 포함한다. 태스크는 제 2 동작 시스템로부터의 호출 가능한 자원의 스레드 소유권의 지속 기간 동안 스레드로 구속된다.
미국 특허 제 5,305,455 호에서, 데이터 처리 시스템은 다수의 스레드를 갖는 하나 이상의 프로세스를 포함하도록 다중 태스킹 모드로 동작 가능하다. 예외관리는 퍼(per) 프로세스 베이시스(basis)에 대향되는 퍼 스레드 베이시스상에서 행해진다.
미국 특허 제 5,247,675 호에서, 다중 태스킹 동작 시스템은 애플리케이션 프로그램이 프로그램 스레드를 실행하는 스케줄에 영향을 주도록 하는 데, 이러한 프로그램 스레드는 프로그램 스레드에 대한 파라미터를 지정함으로써 애플리케이션 프로그램을 구성한다. 이러한 파라미터는 스레드가 존재하는 각 스레드의 우선 순위 레벨 및 디스패치 클래스를 나타낸다.
본 발명은 일반적으로 전기통신 데이터 시스템에서의 실행 메카니즘에 관한 것이다. 특히, 본 발명은 프로세스에서 내부 실행 스레드(internal execution threads)를 관리하는 것에 관한 것이다.
객체 지향 전기통신 애플리케이션을 구현할 때, 그것을 [채널, 톤 센더(tone sender) 등과 같은] 시스템의 자원을 나타내는 객체 모델, 및 애플리케이션 제어 함수를 실행하는 제어 논리로 분할하는 것이 가능하다. 이러한 제어 논리는 호출 제어, 베어러(bearer) 접속 제어 등과 같은 개별 활동으로 분할되는 것이 더 유리하다.
이러한 애플리케이션의 실행 환경은 프로세스이다. 프로세스는 여기서 어떤 활동, 예컨대 전화 호출을 위해 의도된 실행 시간 환경을 의미한다. 프로세스 환경은 전적으로 어떤 프로세서에 지정되고, 메모리[히프(heap), 스택(stack)] 및 실행 능력으로 구성된다. 프로세스내에는 스레드(threads)가 의사-동시에 실행된다. 이러한 프로세스는 또한 객체 모델을 포함한다.
이러한 스레드는 제어 논리에 대한 실행 자원이다. 스레드의 실행은 객체 모델에 의해 발생된 이벤트(event)로 구동된다. 수 개의 스레드는 스레드 우선 순위 순서로 분배되는 동일한 이벤트에 의해 트리거될 수 있다. 이러한 이벤트는 통상적으로 외부 이벤트에 대한 응답, 예컨대 프로세스에 의해 수신된 신호 전송 메시지로서 발생된다.
이러한 스레드는 어떤 특정 객체로부터의 개별 이벤트, 어떤 객체로부터의 어느 이벤트, 객체 클래스로부터의 개별 이벤트, 또는 객체 클래스로부터의 어느 이벤트를 모니터링할 수 있다. 스레드는 자신의 스레드 컨텍스트(context), 즉 스택 및 프로세서 레지스터를 유지하지만, 히프와 모든 다른 스레드를 공유한다.
스레드는 복잡한 활동을 비교적 독립적인 서브-활동으로 분할하기 위한 강력한 지원을 제공한다. 스레드의 논리는 그것이 계속할 이벤트를 필요로 하는 상태로 들어갈 때까지, 또는 그것이 그의 실행을 종료할 때까지 실행한다. 스레드가 대기 상태로 들어가거나, 그의 실행을 종료할 때, 다른 스레드는 실행할 가능성을 부여받는다. 이것은 모든 비동기 이벤트가 처리할 준비가 되어 있을 때 제어 논리로 전송된다는 것을 의미한다.
객체 모델은 ISDN-가입자의 단말기, 접속부, 가입자 등과 같이 애플리케이션에 필요한 실(real) 객체의 추상화(abstraction)로서 사용된다. 이러한 객체는 방법 호출, 예컨대 접속 객체에 의해 제공된 방법 "접속"을 통해 서비스를 제어 논리에 제공한다. 이러한 객체는 데이터를 캡슐화함으로써, 자신의 상태를 유지한다. 객체는 메시지를 다른 프로세스로 전송하고, 그로부터 메시지를 수신함으로써 프로세스 외부의 세계와 또한 통신할 수 있다.
본 발명은 도면을 참고로 하기에서 더 상세하게 설명된다.
도 1은 스레드의 실행을 도시한 도면이다.
도 2는 스레드의 실행을 위한 상태 전이 다이어그램이다.
도 3은 전기통신의 경우에 절단(disconnection) 프로세스를 설명한 도면이다.
도 4 내지 7은 이벤트의 각 관리 상황을 식별하기 위해 사용된 그래픽 프로그래밍 언어에 사용된 심벌을 도시한다.
도 8은 객체 방법 호출 및 이벤트를 통한 스레드 간의 간접 통신을 도시한다.
도 9는 이벤트를 통한 스레드 간의 직접 통신을 도시한다.
도 10은 프로세스 수행 동안 국부 이벤트 큐(local event queue)에서 버퍼링 이벤트를 설명한 그래픽 언어의 심벌을 사용한 도면이다.
도 11은 도 10과 동일한 상황을 설명하는 도면이지만, 포함된 구성 요소 및 메시지에 의한 프로세스를 도시한다.
도 12는 본 발명에 따른 이벤트 메카니즘의 중심 데이터 구조를 도시한 도면이다.
도 13내지 18은 도 12에서 사용된 객체 클래스의 데이터 구조를 도시한다.
도 19 및 20은 2개의 비트 어레이를 도시한다.
대규모 실시간 소프트웨어 시스템, 예컨대 전화 교환기를 제어하는 소프트웨어를 설계할 때, 교환기가 처리해야 하는 실시간 이벤트로부터 발생하는 애플리케이션의 고유 복잡성은 프로그램을 기록, 이해 및 유지하기 어렵게 하는 경향이 종종 있다.
본 발명의 목적은 애플리케이션의 실시간 동작이 더 용이하게 처리되는 것에 의해, 소프트웨어의 복잡성을 감소시켜, 기록, 이해 및 유지하는 것이 더 용이해지는 방식으로 그러한 소프트웨어를 구성하기 위한 메카니즘 및 프레임워크를 제공하는 것이다.
프로세스에서 내부 실행 스레드를 관리하기 위한 본 발명에 따른 시스템에 있어서, 실행 스레드는 프로세스 내부 이벤트 메시지에 의해 구동되는 데, 이러한 메시지는 발생된 내부 또는 외부 인시던트(incident)에 응답하여 이벤트 발생함수(event generating function)에 의해 발생된다. 내부 이벤트 메시지는 우선 순위를 갖는 이벤트 수신 스레드로 분배된다. 이러한 분배는 이벤트 발생 함수의 분배 카테고리를 토대로 이벤트 처리 함수에 의해 제어되고, 이벤트 수신 스레드에 대해서만 실행되는 데, 이러한 이벤트 수신 스레드는 그러한 내부 메시지에 관심을 가지고, 그 발생의 모니터링을 유발시킨다. 각 분배 카테고리에 대해, 전술된 액터(actor), 즉, 다수의 이벤트 수신 스레드, 어떤 이벤트 수신 스레드에 하나의 이벤트 발생 함수에 대한 하나 이상의 모니터링을 표시하는 다수의 제 1 엔티티(entity); 분배 카테고리의 이벤트 발생 함수에 대한 모니터링을 표시하고, 이벤트 수신 스레드를 모니터링했던 제 1 엔티티 모두의 리스트를 각각 갖는 다수의 제 2 엔티티; 상기 제 2 엔티티의 리스트에 의해 분배 카테고리를 모니터링했던 모든 이벤트 수신 스레드의 트랙을 유지하는 하나의 제 3 엔티티; 상기 제 1 엔티티의 리스트를 각각 유지하는 다수의 이벤트 발생 함수가 존재한다.
청구항 2 내지 5에서 나타낸 상기 구조의 다수의 중요한 실시예가 있다.
각각의 제 1 엔티티는, 이벤트 발생 함수에 대한 포인터, 및 이벤트 수신 스레드의 우선 순위에 관한 정보를 유지한다.
각각의 제 2 엔티티는 하나 이상의 제 1 엔티티에 의해 지시되고, 이벤트 수신 스레드에 대한 포인터를 유지하여 분배된 이벤트 메시지를 상기 포인터로 전송한다.
제 2 엔티티의 제 3 엔티티 리스트는 이벤트 수신 스레드로 지시한다.
각각의 이벤트 발생 함수는 이벤트 처리 함수에 대한 포인터를 유지하여 이벤트를 전송한다.
다른 유리한 실시예는 청구항 6 내지 28로부터 나타난다.
객체 지향 전기통신 애플리케이션을 구현할 때, 그것을 (채널, 톤 센더 등과 같은) 시스템의 자원을 나타내는 객체 모델, 및 애플리케이션 제어 함수를 실행하는 제어 논리로 분할하는 것이 가능하다. 이러한 제어 논리는 호출 제어, 베어러 접속 제어 등과 같은 개별 활동으로 분할되는 것이 더 유리하다.
이러한 애플리케이션의 실행 환경은 프로세스이다. 프로세스는 여기서 어떤 활동, 예컨대 전화 호출을 위해 의도된 실행 시간 환경을 의미한다. 프로세스 환경은 전적으로 어떤 프로세서에 지정되고, 메모리(히프, 스택) 및 실행 능력으로 구성된다. 프로세스내에는 스레드가 의사-동시에 실행된다. 이러한 프로세스는 또한 객체 모델을 포함한다.
이러한 스레드는 제어 논리에 대한 실행 자원이다. 스레드의 실행은 객체 모델에 의해 발생된 이벤트로 구동된다. 수 개의 스레드는 스레드 우선 순위 순서로 분배되는 동일한 이벤트에 의해 트리거될 수 있다. 이러한 이벤트는 통상적으로 외부 이벤트에 대한 응답, 예컨대 프로세스에 의해 수신된 신호 전송 메시지로서 발생된다.
이러한 스레드는 어떤 특정 객체로부터의 개별 이벤트, 어떤 객체로부터의 어느 이벤트, 객체 클래스로부터의 개별 이벤트, 또는 객체 클래스로부터의 어느 이벤트를 모니터링할 수 있다. 스레드는 자신의 스레드 컨텍스트, 즉 스택 및 프로세서 레지스터를 유지하지만, 히프를 모든 다른 스레드와 공유한다.
스레드는 복잡한 활동을 비교적 독립적인 부-활동으로 분할하기 위한 강력한 지원을 제공한다. 스레드의 논리는 그것이 계속할 이벤트를 필요로 하는 상태로 들어갈 때까지, 또는 그것이 그의 실행을 종료할 때까지 실행한다. 스레드가 대기 상태로 들어가거나, 그의 실행을 종료할 때, 다른 스레드는 실행할 가능성을 부여받는다. 이는 모든 비동기 이벤트가 처리할 준비가 되어 있을 시에 제어 논리로 전송된다는 것을 의미한다.
객체 모델은 ISDN-가입자의 단말기, 접속부, 가입자 등과 같이 애플리케이션에 필요한 실 객체의 추상화로서 사용된다. 이러한 객체는 방법 호출, 예컨대 접속 객체에 의해 제공된 방법 "접속"을 통해 서비스를 제어 논리에 제공한다. 이러한 객체는 데이터를 캡슐화함으로써, 자신의 상태를 유지한다. 객체는 메시지를 다른 프로세스로 전송하고, 그로부터 메시지를 수신함으로써 프로세스 외부의 세계와 또한 통신할 수 있다.
일예로서, C++ 코드화된 프로그램이 또한 객체 시맨틱스(semantics)에 순응하도록 기록될 수 있을 지라도, 스레드는 주로 그래픽 신택스(syntax)를 갖는 특정한 그래픽 프로그래밍 언어로 코드화된 프로그램에 의해 사용된 객체 시맨틱스를 지원하도록 특별히 설계되는 것으로 가정된다.
이와 같이 상술한 것의 일예로서, 도 1은 각 제어 논리에 대한 실행 자원으로서 작용하는 2개의 스레드(104 및 106)를 갖는 프로세스(102)를 도시한다. 스레드(104 및 106)의 실행은 프로세스내의 객체 논리에 의해 발생되고, 각 스레드(104 및 106)에 속하는 국부 이벤트 큐(112 및 114)에 의해 관리되는 이벤트(108 및110) 각각에 의해 구동된다. 이러한 프로세스는 도시되지 않은 액세스 프로세스로부터 액세스 에이전트 객체(118)에 의해 수신되는 메시지(116)에 의해 개시된다. 액세스 에이전트 객체(118)는 결과적으로 스레드(104)로 분배되어 이러한 스레드의 실행을 개시하도록 하는 이벤트(108)를 발생시킨다. 스레드(104)의 실행 제어 논리는 객체(122)로의 방법 호출(120)을 실행시키며, 이러한 객체(122)는 결과적으로 스레드(106)로 분배되어 이러한 스레드의 실행을 개시하도록 하는 이벤트(110)를 발생시킨다.
도 2에는 스레드의 실행을 위한 상태 전이 다이어그램이 도시되어 있다. 개시 및 종료 상태는 도시되지 않으나, 다음에서 명백해진다.
새로운 스레드가 발생될 때 즉시 실행을 개시하지 않으나, "개시 이벤트 상태 대기(waiting for start event state)"(202)에서 그 자신에 배치하는 개시 이벤트를 대기한다. 화살표(204)로 표시된 개시 이벤트를 수신할 시에, 스레드의 실행은 상태 "실행"(206)으로 표시된 바와 같이 개시한다. 실행 시에, 스레드는 어떤 이벤트가 발생하도록 대기하는 대기 상태로 들어갈 수 있다.
사실상, 스레드가 대기 상태로 들어가면, 스레드는 대기 이벤트가 이미 발생되었는지 여부에 의존한다. 그것이 이미 발생한 경우, 스레드가 화살표(208)로 표시된 바와 같이 상태 "버퍼 실행(executing-with-buffered)"(210)에 들어갈 지라도, 스레드가 실행을 계속하는 한편, 화살표(212)로 표시된 바와 같이 발생된 이벤트를 대기한다. 그렇지 않으면, 즉, 이벤트가 아직 발생하지 않은 경우, 2개의 대기 상태(218 또는 220) 중 하나는 들어가게 된다. "이벤트 대기(waiting forevent)" 상태(214)는 개별 이벤트를 대기하는데 사용된다, "이벤트 대기" 및 "대기 이벤트 수신"의 천이 화살표는 각각 216 및 218로 표시된다. "어느 이벤트 대기"상태(216)는 어느 이벤트를 대기하는데 사용된다. "어느 이벤트 대기" 및 "대기 이벤트 수신"의 천이 화살표는 각각 222 및 224로 표시된다. 2개의 대기 상태를 갖는 이유는, 스레드가 다시 막 개시되려고 할 때, 발생된 이벤트의 결과로서, 국부 이벤트 큐에 이벤트를 정합할 시에 스레드는 상이한 전략을 사용한다는 것인데: 즉 어느 이벤트를 대기하면, 이벤트는 항상 "정합"되고, 그렇지 않으면, 국부 이벤트 큐를 통한 탐색이 행해져야 한다. 정합이 있으면, 스레드는 다시 실행을 개시하여, "실행" 상태(206)로 들어간다.
"버퍼 실행"(210) 상태에 있을 때, 스레드는 어떤 이벤트가 발생하도록 대기할 수 있다. 이벤트가 이미 발생하였다면(그것은 국부 이벤트 큐에서 발견됨), 동일한 상태에서 즉시 실행이 계속되고, 그렇지 않으면, 스레드는 대기 상태(214 또는 216) 중 하나로 들어간다.
도 2에는 종료 상태가 존재하지 않지만, 스레드의 주 함수가 복귀할 시에 종료된다. 복귀할 주 함수를 위해, 스레드가 실행 중이어야 하므로, "실행" 상태(206) 또는 "버퍼 실행" 상태(212) 중 어느 하나로부터 종료 상태로 천이할 수 있다.
이벤트는, 모든 관심을 둔 스레드가 그것을 수신하여 처리할 가능성을 가질 때까지 삭제되지 않아야 한다. 이러한 상황이 발생했을 시기를 결정하는 문제는 이벤트 및 스레드 블록간의 협력에 의해 해결된다. 일반적으로, 이벤트는 관심을 둔모든 스레드로 분배된 후에 자신을 삭제하지만, 스레드가 항상 수신과 동시에 이벤트를 처리하지 않으므로, 이벤트가 분배 직후에 삭제되지 않도록 방법이 취해져야 한다. 이러한 상황은 스레드가 현재 대기하지 않는 이벤트를 수신할 때에 발생한다. 스레드는 이벤트가 삭제될 수 있도록 이벤트를 대기하여 처리한 후에만 존재한다.
얼마나 많은 기준의 트랙을 존재하는 이벤트에 대해 유지하도록 기준 카운터가 사용된다. 이 카운터가 0으로 감소될 때, 이벤트는 자신을 삭제한다. 이 카운터는, 수신된 이벤트가 스레드내에서 버퍼될 때 증가되고, 스레드가 버퍼 이벤트를 대기하고, 새로운 대기 상태에 도달하거나 소멸할 때 감소된다. 스레드가 소멸될 때, 모든 버퍼 이벤트의 기준 카운터는 감소되어야 한다. 이에 대한 부가적인 설명은 이후 이벤트 블록에 대한 상세한 설명과 관련하여 이루어진다.
객체 상호 동작에 관해서, 스레드 클래스는 2개의 실행 스레드-컨텍스트, 즉 현재의 스레드-컨텍스트 및 스레드 자신의 스레드-컨텍스트간의 스위칭을 관리한다. 스레드가 대기하고 있는 이벤트를 수신할 때, 현재의 스레드-컨텍스트가 저장되고, 스레드 자신의 스레드-컨텍스트로의 스위치가 행해진다. 스레드가 국부 이벤트 큐내에 없는 이벤트의 대기를 원할 때, 다른 스레드에 실행할 가능성이 주어진다.
스레드 자신의 스레드-컨텍스트로의 스위치는, 스레드가 대기하고 있는 이벤트가 수신될 때에만 행해진다. 따라서, 특정한 절차는 스레드를 개시하도록 실행된다. 먼저, 스레드 구성자(constructor)는 특정한 개시 이벤트의 모니터링을 설정한다. 그 후, 대응하는 이벤트가 생성되어 배치된다. 나중에, 스레드는 이벤트를 수신하여, 그것을 통상적으로 수신된 이벤트와 같이 처리하고, 그것을 스레드가 대기하고 있는 이벤트로서 인식함으로써, 스레드의 실행을 개시한다.
이벤트는, 내부 또는 외부 인시던트(incident)가 특정한 프로세스에서 발생하자 마자 관심을 둔 모든 스레드에게 통지함으로써 스레드의 실행을 조정하는데 사용된다. 그러한 인시던트의 예는 호출(외부) 및 타임아웃(내부)을 절단한 것이다. 다시 말하면, 이벤트 함수는 프로세스내에서 통신하기 위한 메카니즘을 지원한다.
이벤트는 스레드의 실행을 개시한다. 이벤트는 예정된 수신기를 갖는 것이 아니라, 특정한 이벤트에서 그의 관심을 선언하는 스레드로 분배된다. 이벤트 함수때문에, 객체 논리 및 제어 논리를 독립적으로 구성하는 것이 가능하다. 이벤트가 이름, 센더, 및 발생기로부터 스레드로의 관련 데이터 반송 정보로 구성되고, 프로세스내에서만 존재한다.
이벤트는, 통상 수신된 메시지, 예컨대 가입자가 후크 온(hook on)을 한 메시지의 결과로서 프로세스에서 객체에 의해 발생된다.
이벤트의 지정(specification)은 그래픽 언어 및 디자인 언어를 결합하여 실행된다. 제어 논리는 상술한 바와 같이 그래픽 언어의 플로우스크립트(flowscripts)에 의해 지정되는 반면, 객체 논리를 구성하는 객체는 디자인 언어로 객체 형 또는 클래스 지정에 의해 지정될 수 있다.
이벤트 처리는 다음과 같이 다수의 특징적인 특성을 갖는다.
- 이벤트는 그것에 모니터링되었던 모든 스레드로 분배된다. 프로세스내에서 발생된 모든 이벤트는 일반적인 "문자 박스(letter box)"로 종료하는 데, 이러한 문자 박스는 상술한 "이벤트 핸들러(handler)"이고, 이것으로부터 상기 이벤트는 이러한 이벤트에서 관심을 표시하는 모든 스레드로 전송된다. 어떤 것도 상기 특정한 이벤트에 관심을 갖지 않으면, 그것들은 버려진다. 이러한 관심 표시, 즉, 이벤트의 모니터링 순서 표시는 플로우(flow)에서 명백하게 행해져야 한다.
- 이벤트가 상기 특정한 이벤트에서 그의 관심을 모니터링했던 스레드로 분배될 때, 스레드는 아직 그것을 처리할 준비가 되어 있지 않다. 이것은 실행이 이러한 이벤트의 대기-상태에 아직 도달하지 않거나, 또는 다른 스레드가 그 순간에 실행하는 경우일 수 있다. 그 후, 이벤트는 스레드에 속하는 큐에 놓여진다[도 1의 국부 이벤트 큐(112 및 114) 참조]. 스레드가 이벤트를 처리할 준비가 되어 있을때, 그것은 국부 이벤트-큐로부터 이벤트를 인출한다.
그 후, 새로운 이벤트가 요구되어 진행하는 법을 결정할 때까지 실행이 계속된다. 이러한 이벤트는 타임아웃과 같은 다른 외부 이벤트 또는 내부 이벤트일 수 있다[도 1의 이벤트(108 및 110) 참조].
- 브로드캐스트/액티브(Broadcast/Active) 수신. 이벤트 발생기 관점으로부터, 이벤트는 특정한 수신자(recipient)에게 전송될 수 없다. 발생된 모든 이벤트는 전송 스레드를 포함하는 이벤트를 모니터링했던 모든 스레드로 분배된다. 이의 개념은 이벤트를 발생시키는 엔티티가 이벤트에 관심을 둔 엔티티를 알지 못한다는 것을 의미한다. 수신기는 대기할 시기와 대기 대상("액티브 수신")을 결정한다.
- 실행은 의사-병렬(pseudo-parallel)로 수행된다. 스레드는 의사-병렬, 즉 한 번에 하나씩 실행한다 스레드에서의 모든 실행은 스레드가 대기하고 있는 이벤트를 수신할 시에 개시하고, 그 후 스레드는 자신을 다시 대기 상태로 놓거나 그의 실행을 종료할 때까지 방해받지 않고 실행한다. 그 스테이지에서, 다른 스레드는 실행하여, 그 이벤트 또는 다른 이벤트에 의해 트리거된다. 방금 설명된 것은 예컨대 도 1의 스레드(104 및 106)에 대해 사실일 수 있다.
이벤트는 배치된 순서로 스레드에 분배된다. 그러나, 하나의 단일 이벤트가 하나 이상의 스레드에 분배될 수 있기 때문에, 스레드는 그러한 경우에 분배 순서로 표시하는 우선 순위를 갖는다. 스레드는 또한 수신된 이벤트의 부가적인 분배를 방지하고, 낮은 우선 순위의 스레드가 이벤트를 수신하지 못하게 한다.
스레드가 이벤트를 수신할 수 있도록 하기 위해, 스레드는 그것이 배치되기 전에 이벤트를 명백히 모니터링해야 한다. 모니터링에 의해, 스레드는 어떤 객체(또는 객체들)로부터 어떤 이벤트(또는 이벤트들)에서의 관심을 선언한다. 이벤트가 배치되기 전에 모니터링이 행해지는 경우, 모니터링은 이벤트가 해당 스레드로 분배되도록 한다. 스레드는 또한 이미 행해진 모니터링을 제거함으로써, 해당 이벤트(또는 이벤트들)가 스레드로 더 분배되는 것을 방지할 수 있다.
도 3은 프로세스(302)내에서 실행된 절단을 도시한다. 이러한 절단은 도시되지 않은 액세스 프로세스로부터 절단 메시지(304)에 의해 개시된다. 액세스 에이전트(306)의 객체 논리는 이벤트(308)에 의한 결과로서 어떤 절단 제어 논리가 실행되고 있는 곳에서 스레드(310)를 트리그(trig)한다. 이러한 논리는, 화살표(312)로표시된 바와 같이, 타이머 객체의 인스턴스(instance)(314)를 생성하도록 요청함으로써 타이밍 함수를 개시시킨다.
그 후, 스레드(310)의 제어 논리의 실행은 타임아웃 또는 외부 세계로부터의 다른 메시지 중 하나일 수 있는 새로운 이벤트를 대기하는 정지(stop)에 이른다. 예에서, 타임아웃 메시지(316)는 타임아웃 이벤트를 스레드(310)로 전송하는 인스턴스(314)에 의해 수신되는 데, 이러한 스레드(310)는 절단 메시지(318 및 320)를 호출 객체(322) 및 원격 대화 객체(324) 각각으로 귀착시키는 스레드(310)의 함수 논리의 실행을 다시 개시한다.
이벤트 처리 메카니즘은 다음의 서비스를 제공한다.
- 배치한 이벤트. 이벤트 발생으로 정의되는 객체는 발생된 이벤트를 전송할 수 있다. 통상적인 케이스는, 이벤트가 내부 또는 외부 인시던트, 예컨대 가입자로부터의 후크 온 또는 시간 감시의 해제의 결과로서 발생될 시에 나타난다.
- 모니터링 이벤트. 이벤트 수신 스레드는 수신하기를 바라는 어떤 이벤트에 대한 관심을 알릴 수 있다. 어떤 스레드에 의해 발생된 하나의 특정한 이벤트 또는 모든 가능한 이벤트에 대한 관심은 특정한 가입 순서로 지정된다. 이벤트가 발생되어 전송되면, 그것은 그 이벤트에 가입한 수신 스레드에 도달한다.
- 이벤트의 모니터링 취소. 이벤트에 대해 더 이상 관심이 없는 스레드는 그의 모니터링을 취소할 수 있다.
- 이벤트의 부가적인 분배 방지. 스레드는 수신 후에 이벤트가 더 이상 분배되지 않도록 방지할 수 있다. 이러한 이벤트를 "제거(killing)"함으로써, 이벤트를아직 수신하지 않은 스레드는 결코 그렇게 할 수 없다.
이러한 서비스 중 각각은 다음에서 더 철저하게 설명된다.
이벤트를 배치한다는 것은 발생된 이벤트가 중심 객체, 즉, 이벤트를 관심있는 스레드로 분배하는 이벤트 핸들러로 전송된다는 것을 의미한다. 이미 언급했듯이, 이벤트는 외부 또는 내부 인시던트의 결과로서 발생된다. 외부 인시던트는 통상적으로 프로세스내에서 이벤트 발생기에 의해 이벤트로 변환되는 메시지로서 프로세스에 보고된다. 나중에 이벤트가 분배될 때, 이벤트가 배치되는 것과 동일한 순서로 행해진다.
이벤트를 배치하기 위한 그래픽 프로그래밍 언어의 신택스(syntax)는 예컨대 도 4에 도시된 종류의 이벤트를 배치하기 위한 심볼을 포함할 수 있다. 이벤트를 모니터링했던 모든 대기 스레드는 그것을 수신한다. 도시된 바와 같이, 심볼은 전송된 이벤트의 이름을 포함한다. 심볼 입력 파라미터 데이터는, 아래의 부가적인 설명으로부터 명백하듯이, 이벤트로도 배치될 수 있다. 심볼은 결과치없이 출구(exit)를 갖고, 실행될 다음 노드로 직접 지시한다.
시맨틱스의 관점으로부터, 실행된 스레드는 예컨대 이벤트 "EventName"을 발생시킨다. 포함된 데이터를 갖는 상기 이벤트는 이를 기다리는 모든 스레드로 배치된다. 이미 언급했듯이, 이벤트는 특정한 스레드에 배치될 수 없다.
특정한 이벤트에 관심이 있는 모든 스레드는 이러한 이벤트의 모니터링의 순서를 매기고, 즉, 어떤 이벤트에 이벤트 수신자의 관심을 알림으로써 그의 관심을 지정해야 한다. 특이하게 이벤트를 식별하는 데이터를 포함한 모니터 객체를 작성함으로써 모니터링이 행해진다. 다시 말하면, 모니터 객체는 이벤트 수신기를 대신해서 이벤트에 대한 관심을 알린다. 그래픽 프로그래밍 언어에서의 신택스는 예컨대 업라이트 블랙 플래그(upright black flag)를 갖는 롬(rhomb)인 도 5에 도시된 심볼에 의해 개시 모니터링 이벤트를 지정한다. 이러한 심볼내에 지정된 하나 이상의 센더 및 하나의 이벤트가 항상 존재한다.
도 4 및 5에 도시되고, 상술한 2개의 심볼 각각은 실행될 다음 노드로 지시한 하나의 출력 화살표만을 갖고, 어떤 결과치도 화살표에 부착되지 않는다.
모니터링되기를 바라는 이벤트의 수 및 상이한 센더의 수에 따라, "이벤트 모니터링 개시(start to monitor an event)"를 지정하는 4개의 상이한 가능성이 있는 데, 상기 상이한 센더로부터 이벤트가 발생한다. 이러한 가능성은 다음과 같다:
- 어떤 센더로부터 하나의 이벤트를 모니터링.
- 어떤 센더로부터 어느 이벤트를 모니터링.
- 센더의 클래스로부터 하나의 이벤트를 모니터링.
- 센더의 클래스로부터 어느 이벤트를 모니터링.
시맨틱스의 관점으로부터, 모니터링 개시를 위한 심볼이 플로우(flow)로 실행될 때, 지정된 이벤트의 모든 인스턴스는 그것이 발생할 때마다 이러한 플로우로 분배된다는 것에 주목해야 한다. 그 후, 이러한 이벤트는 플로우에 의해 디스패치(dispatch)될 때까지 스레드의 국부 이벤트 큐에서 대기 행렬된다.
센더의 클래스로부터 이벤트를 모니터링한다는 것은 클래스의 어느 인스턴스가 이벤트를 배치시킬 경우 이벤트가 수신기에 전송된다는 것을 의미한다.
상술한 바와 같이, 진행시키기 위해 객체 또는 다른 스레드로부터 어떤 정보를 필요로 하는 스레드는 자신을 대기 상태로 놓을 수 있다. 이러한 스레드의 실행은 그 때 정지되고, 어떤 다른 스레드는 동작을 개시한다. 바람직한 정보가 이벤트의 형태로 수신될 시에 실행이 재개되지만, 현재 활동 스레드가 실행을 정지하지 않았을 시에는 재개되지 않는다.
도 6은 그래픽 프로그래밍 언어로 표시된 것처럼 플로우에서의 대기 상태를 도시한다. 정확한 대기 상태는 타원체(oval)(602)로 심볼화되는 데, 이것으로부터 화살표(604, 606, 608 및 610)는 심볼(612.1, 612.2, . . . 612.n)을 지시한다. 이러한 심볼은 상이한 센더를 나타내며, 각 심볼 아래의 부가적인 화살표는 스레드(플로우)가 각 센더로부터 대기하는 이벤트를 나타낸다. 도 6에서 알 수 있듯이, 이러한 이벤트는 각 센더(612.1, 612.2 및 612.n)에 대해 ev1, ev2, ev3; ev4, ev5 및 ev8, ev9로서 나타낸다. 이러한 센더의 이름은 심볼내에 포함된다. 아래에 더 설명되는 바와 같이, 별표를 포함하는 심볼이 또한 사용될 수 있다. 대기 상태는 이름을 가질 수 있다. 그것은 또한 그것과 관련된 조건 리스트를 가질 수 있다.
플로우의 실행이 대기 상태에 도달할 때, 만약 있다면 조건 리스트가 먼저 시험된다. 이러한 조건이 충족되지 않으면, 에러가 있다는 것이다. 조건이 충족되거나, 또한 어떠한 조건 리스트도 없다면, 대기 상태가 도달되기 때문에 실행은 정지한다. 주어진 이벤트 중 하나가 이벤트를 결합한 센더로부터 수신될 때 실행이 재개된다. 그 후, 실행은 발생된 이벤트에 의해 명명되는 화살표에 따른다.
센더의 이름으로서는 다음과 같이 적용될 수 있다:
- 객체 인스턴스로 지시하는 변수. 이벤트는 재개될 실행을 위해 주어진 객체 인스턴스로부터 발생되어야 한다.
- 스레드 아이덴티티(identity). 이벤트는 재개될 실행을 위해 주어진 스레드 인스턴스로부터 발생되어야 한다.
- 별표(*). 이것은, 어느 주지된 이벤트가 이를 발생시키는 것이 객체 또는 스레드 중 어느 것일 지라도 관심을 둔다는 것을 의미한다.
이벤트 수신기가 이벤트에 더 이상 관심이 없다면, 이전에 행해진 모니터링이 제거될 수 있다. 모니터링 제거는, 이벤트 수신기에 이벤트에 대한 그의 관심이 알려졌을 시에 작성된 모니터 객체를 제거함으로써 달성된다.
프로그래밍 언어에서, 정지 모니터링 이벤트는 예컨대 도 7에 예시된 심볼에 의해 지정될 수 있다. 도시했듯이, 이러한 심볼은, 하위 플래그를 갖는다는 점에서 도 5의 것과 다르다. 심볼로 지정된 하나 이상의 센더 및 하나의 이벤트가 항상 있다. 심볼은 실행될 다음 노드로 지시하는 하나의 아웃고잉 화살표만을 가지며, 어떤 결과치도 화살표에 부착되지 않는다. 심볼 정지 모니터링이 플로우로 실행될때, 지정된 이벤트의 인스턴스는 더 이상 플로우에 의해 수신되지 않는다.
이벤트 발생 객체를 삭제할 시에 자동으로 발생되는 미리 정해진 하나의 단일 이벤트, 즉 이벤트 DEATH가 존재한다. 이벤트 DEATH는 모니터링되어, 어느 다른 이벤트처럼 수신될 수 있지만, 어느 데이터를 반송할 수 없다. 키워드 DEATH는 이러한 이벤트를 참조할 때마다 사용된다.
스레드 간의 통신을 위한 가능성이 얼마간 존재한다. 하나는 객체 방법 호출을 통한 통신이다. 객체는 그들이 어떤 방법을 실행할 시에 이벤트를 발생시킬 수 있다. 이벤트는 그 때 관심이 있는 모든 스레드로 전송된다. 이는 도 8에 예로서 도시되어 있다. 스레드(802)는 화살표(804)인 방법 호출을 객체(806)로 보낸다. 객체(806)는 차례로 이벤트(808)를 다른 스레드(810)로 보낸다. 이러한 방식으로, 2개의 스레드 간의 통신이 가능하다. 이러한 메카니즘을 적절한 방식으로 결합함으로써, 2개의 스레드가 "서로 대화(talk to each other)"를 할 수 있게 한다.
플로우 자신, 즉, 스레드는 또한 이벤트를 발생시킬 수 있다. 이것은, 이벤트를 서로 전송하고, 이벤트를 서로 수신함으로써, 2개 이상의 스레드가 서로 직접 대화할 수 있다는 것을 의미한다. 이것은 예로서 도 9에 도시되고, 여기서, 스레드(902)는 이벤트(904)를 다른 스레드(906)로 보낸다. 간략화된 도면이 이벤트를 스레드 사이로 직접 전송하는 것을 제시하는 것으로 보이지만, 이것은 그러한 경우가 아님을 주목해야 한다. 이러한 이벤트는 도시되지 않은 이벤트 핸들러를 통해 분배된다.
이제, 프로세스에서 발생의 플로우 챠트를 도시한 도 10 및, 이러한 프로세스 및 그 구성의 일부를 도시한 도 11이 참조되는 데, 여기서 프로세스는 1102로 표시된다. 모니터링된 이벤트는 스레드에 의해 국부 이벤트 큐에서 버퍼링될 수 있다. 버퍼링(buffering)은 이벤트가 모니터링된 후 그것의 모든 발생이 관찰될 수 있는 것을 의미하고, 반면에 모니터링이 발행되기 전에 발생하는 이벤트는 사용될 수 없다. 이벤트가 더 이상 바람직하지 않다면, 모니터링은 제거되어야 한다. 이미 수신된 이벤트는 그들이 "대기" 상태에 있을 때까지 국부 이벤트 큐에 남아 있는데, 이 경우에 스레드는 그의 실행을 계속하게 된다. 스레드가 이벤트를 "대기"할시에 이벤트가 아직 발생하지 않았다면, 스레드의 실행은 이벤트가 발생할 때까지 유휴 상태에 있게 된다.
도 10에서, 1002는 도 11의 프로세스(1102)의 제 1 단계로서, 이벤트(e1)의 모니터링의 개시를 나타내며, 이의 소스는 이벤트 발생기(EG1)이다. 소스가 이벤트 발생기(EG2)인 이벤트(e2)의 모니터링 개시는 1004로 표시된다. 도 11은 제각기 프로세스(1102)에 포함되는 이벤트 발생기(EG1 및 EG2)(1104 및 1106)를 표시한다. 프로세스(1102)는 또한 국부 이벤트 큐(1110)를 갖는 스레드(1108)를 포함한다.
도 10에서, 1006은 이벤트(e2)의 발생이 실행을 정지하는 동안에 대기하는 대기 상태를 나타낸다. 1008에서는 이벤트 발생기(EG1)로부터의 이벤트(e1)가 발생하는 것을 나타내고, 도 11의 화살표(1112)는 이벤트(e1)가 국부 이벤트 큐(1110)에서 버퍼링되는 것을 나타낸다. 도 10의 1010에서는 이벤트 발생기(EG2)로부터의 이벤트(e2)가 발생하는 것을 나타내고, 1012에서는 그의 개시 실행을 나타낸다.
도 10의 심볼(1014)은 이벤트(e1)의 대기 시의 실행 정지를 나타낸다. 이러한 이벤트는 이미 발생하여, 그의 개시 실행은 1016으로 나타낸다.
이벤트 구동 프로그램 스레드를 스케줄링(scheduling)하는 방법은 도 12를 참조로 더욱 상세하게 설명된다. 이러한 설명에서, 특정 클래스 구조에 포함되어 있는 객체 클래스가 기술된다. 이러한 클래스는 그의 이름이 다음에서 턴 업(turn up)함에 따라 더욱 상세하게 설명된다.
도 12에서, 블록(1202 내지 1206)은 베이스 클래스 EventGenerator의 각 객체 이벤트 발생기를 나타내고, 이의 객체는 부가적인 분배를 위해 이벤트 처리 메카니즘의 중심 서비스 클래스 EventHandler의 이벤트 핸들러 객체에 이벤트를 배치할 수 있다. 블록(1208 내지 1212)은 계승(inheritance)에 의해 이벤트 객체의 수신을 가능하게 하는 추상(abstract) 베이스 클래스 EventReceiver의 각 객체 이벤트 수신기(스레드)를 나타낸다.
클래스 명명된 이벤트는 프로세스 이벤트를 나타낸다. 이벤트 객체는 태그 및 소스, 이벤트 발생기에 의해 유일하게 정의된다. 각 이벤트 발생기는 클래스 DistCat의 어떤 분배 카테고리의 멤버인 데, 이에 의해 이벤트 발생기의 그룹의 모니터링을 가능하게 한다. 도 13을 참조하면, EventGenerator는 구현을 위해 다음과 같은 객체를 사용한다:
- 이벤트의 배치를 진행하고, 발생기의 생성 및 파괴를 알리는 EventHandler.
- 어떤 분배 카테고리의 소속(membership)을 위한 DistCat.
- 발생기로부터 이벤트에 대한 모든 모니터링의 트랙을 유지하는 MonItem.
인터페이스를 위해, EventGenerator는 Event를 사용하여 이벤트를 배치한다.
EventHandler는 중심 클래스이고, 모든 모니터링, 이벤트 발생기 및 이벤트 수신기의 트랙을 유지하기 위한 구조가 유지된다.
도 14를 참조하면, EventHandler는 구현을 위해 다음과 같은 객체 클래스를 사용한다;
- 개별 이벤트 발생기에 대한 모든 모니터링의 트랙을 유지하는 MonItem.
- 이벤트 발생기가 어느 분배 카테고리에 속하는 트랙을 유지하는 DistCatNode. 노드는 2진 트리(tree)로 유지된다.
- 분배 시간까지 이벤트를 보관하여 그들을 수신기에 전송하기 위한 이벤트.
- 분배 카테고리에 대한 모든 모니터링의 트랙을 유지하는 ErItem.
- 이벤트 수신기가 파괴된 트랙을 유지하는 DeadErList.
- 내부 객체의 할당을 위한 메모리.
인터페이스를 위해, EventHandler는 다음과 같은 객체 클래스를 사용한다:
- 분배 카테고리에 대한 모니터링을 등록하기 위한 DistCat.
- 모니터링을 등록하기 위한 EventReceiver.
- 개별 이벤트 발생기에 대한 모니터링을 등록하기 위한 EventGenerator.
EventReceiver는 계승에 의해 이벤트를 수신할 가능성을 유도된 클래스에 부가하는 추상 베이스 클래스이다. 스레드는 EventReceiver로부터 유도된다.
도 15를 참조하면, EventReceiver는 수신기의 구성 및 파괴의 표시를 전달하기 위한 클래스 EventHandler를 구현하기 위해 사용한다.
인터페이스를 위해, EventReceiver는 수신기로부터 유도된 클래스로 전달되는 클래스 Event를 사용한다.
도 12를 참조하면, 블록(1214)은 2진 트리 DistCatTree에서의 노드인 객체 DistCatNode(분배 카테고리 노드)를 나타낸다. DistCatTree는 클래스 ErItem(이벤트 수신기 항목)의 객체의 리스트를 포함한다. 이러한 클래스는 분배 카테고리의 모니터링의 트랙을 유지하기 위해 사용된다. 각 객체 ErItem은 이벤트 수신기로의포인터를 유지하고, 분배된 이벤트를 이벤트 수신기로 전송한다. 블록(1216 내지 1220)은 이벤트 수신기(1208 내지 1212) 중 각 하나로 지시하는 각 포인터(1222 내지 1226)를 갖는 각 ErItem 객체를 나타낸다.
DistCatNode는 하나의 분배 카테고리의 모든 이벤트 수신기의 트랙을 유지한다. 도 16을 참조하면, DistCatNode는 BinTreeNode를 계승함으로써, 이벤트 핸들러에 의해 고속 조사를 위한 2진 트리의 멤버인 특성을 갖는다. 구현을 위해, DistCatNode는 분배 카테고리를 기억하는 DistCat, 및 동일한 분배 카테고리의 모든 이벤트 수신기(모니터링을 행하는 모든 이벤트 수신기는 내부 구조에서의 ErItem로 표시됨)의 링을 유지하는 ErItem을 이용한다. 상기 및 하기에 부가적으로 나타나는 단어 "링"은 방금 언급된 이벤트 수신기와 같은 링크된 엔티티의 리스트의 특성을 나타내는 데에 사용되는 데, 여기서 리스트의 최종 엔티티는 리스트의 최초 엔티티로 되돌아 지시한다. 링을 참조하는 이유는 예로서 도 12에 도시된 실시예가 이러한 형태의 리스트에 의존한다는 사실이다. 그러나, 문제의 리스트는 링크된 링의 형태로 있을 필요가 없다.
도 17을 참조하면, 클래스 ErItem은 내부 구조에서의 모니터링된 이벤트 수신기를 나타낸다. 그것은 분배 카테고리에 대한 모니터링의 트랙을 유지하고, 이의 이벤트는 이벤트 수신기에 의해 수신된다. 그것은 또한 (MonItem으로 표시된) 개별적인 이벤트 발생기에 대한 모든 모니터링의 링을 유지하고, 이의 이벤트는 이벤트 수신기에 의해 수신된다.
ErItem은 RingLink를 승계함으로써, 동일한 분배 카테고리의 모든 ErItem이함께 링크될 수 있다.
구현을 위해, ErItem은 다음과 같은 클래스를 사용한다:
- receiveEvent 및 handleDeadlock 함수 호출을 전송하기 위한 EventReceiver.
- 해당 수신기용의 개별적인 이벤트 발생기에 대한 모든 모니터링의 링을 유지하기 위한 MonItem.
- ErItem이 파괴될 시에 ErItem의 DistCatNode 링으로부터 ErItem이 비링크(unlink)될 수 있도록 하는 DistCatNode.
- ErItem이 점유된 메모리를 정확히 복귀시키도록 하는 Memory.
- 발생된 태그를 모니터링에 정합할 시와, 모니터링을 갱신 및 "다운데이트(downdating)"할 시의 EventTag.
인터페이스를 위해, ErItem은 이벤트를 분배할 시에 대응하는 이벤트 수신기로 전송되는 이벤트를 사용한다.
도 12에서는 각 ErItem 객체가 또한 클래스 MonItem(모니터링 항목)의 객체 리스트를 유지한다. 이러한 클래스는 개별적인 이벤트 발생기의 모니터링의 트랙을 유지하기 위해 사용된다. 블록(1228 내지 1238)은 각 MonItem 객체를 나타낸다.
도 18을 참조하면, MonItem은 개별적인 이벤트 발생기의 모니터링의 내부 표시이다.
MonItem은 다음의 것을 승계한다:
- 링의 멤버일 수 있도록 ErItem이 그의 이벤트 수신기에 대한 모든 개별적인 모니터링을 유지하는 ErMonLink.
- 이벤트 발생기의 멤버일 수 있도록 MonItem의 링, 즉 링의 모든 개별적인 모니터링이 이벤트 발생기를 위해 행해지는 EgMonLink
구현을 위해, MonItem은 다음의 클래스를 사용한다:
- 이벤트 수신기로의 포인터를 유지하는 ErItem로의 포인터를 유지하기 위한 ErItem.
- 발생된 이벤트 태그를 모니터링에 정합할 시와, 모니터링을 갱신 및 "다운데이트"할 시의 EventTag.
- ErItem이 점유된 메모리를 정확히 복귀시키도록 하는 Memory.
도 12에서는, DistCatTree를 통해 모든 ErItem에 도달할 수 있다. 객체(1214)와 같이 트리(tree)에 포함된 각 DistCatNode 객체는, 객체(1202 내지 1206)와 같은 개별적인 이벤트 발생기 또는 분배 카테고리 중 어느 하나의 모니터링을 나타내도록 작성된 객체(1216 내지 1220)와 같은 모든 ErItem의 링을 포함한다. 도 12에서, 링은 ErItem 객체(1216 내지 1220)를 함께 연결한 화살표(1240, 1242 및 1244)로 표시된다. 하나의 DistCatNode의 링에서의 모든 ErItem은 동일한 분배 카테고리의 이벤트 발생기에 대한 모니터링의 결과이다.
일반적으로, ErItem은 링으로 링크되는 데, 여기서 각 링은 어떤 DistCatNode에 속한다. 링은 수신기의 우선 순위에 따라 순서 배열된다. ErItem은, 이전에 모니터링되지 않았던 이벤트 수신기에 대한 모니터링이 행해질 시에 작성된다. ErItem은 그 때 모니터링의 이벤트 발생기의 분배 카테고리에 대응하는DistCatNode에 속하는 ErItem의 링으로 링크된다.
ErItem은 본래 receiveEvent 및 handleDeadlock 함수 호출을 전송하기 위해 대응하는 이벤트 수신기, 예컨대, 이벤트 수신기(1208 내지 1212)로의 포인터, 예컨대, 포인터(1222 내지 1226)를 갖는다. 더욱이, 각 ErItem은 ErItem의 DistCatNode의 링으로부터 고속 비링크하기 위한 DistCatNode, 예컨대 노드(1214)로의 포인터를 갖는다. 도 12에서, 그러한 포인터는 각 ErItem(1216 내지 1220)로부터 발신하는 일반적인 화살표(1246)로 표시된다. 각 ErItem은 또한 MonItem의 링인 멤버를 갖는다. ErItem(1216)에 대해 그러한 링은 MonItem(1228 내지 1232)을 포함하고, 화살표(1248 내지 1252)로 표시된다. ErItem(1218)에 대해 링은 MonItem(1234 및 1236)을 포함하고, 화살표(1254 및 1256)로 표시된다. ErItem(1220)의 "링"은 단일 MonItem(1238)를 포함하고, 화살표(1258)로 표시된다.
각 MonItem(1228 내지 1238)은 개별적인 이벤트 발생기의 모니터링을 나타낸다. 따라서, MonItem(1228, 1234 및 1238)은 이벤트 발생기(1202)의 모니터링을 나타내고, 각 MonItem(1228, 1234, 1238)으로부터 발신하는 화살표(1260)로 표시된다. 동일한 방식으로, MonItem(1230 및 1236)은 이벤트 발생기(1204)의 모니터링을 나타내고, 각 MonItem(1230 및 1236)으로부터 발신하는 화살표(1262)로 표시되며, MonItem(1232)은 이벤트 발생기(1206)의 모니터링을 나타내고, 화살표(1264)로 표시된다. 각 경우에, 모니터링 이벤트 수신기는 ErItem에 의해 지시된 것이다. 따라서, MonItem(1228, 1230 및 1232)에 대해, ErItem(1216)은 이벤트 수신기(1208)로 지시하고, MonItem(1234 및 1236)에 대해, ErItem(1218)은 이벤트 수신기(1210)로지시하며, MonItem(1238)에 대해, ErItem(1220)은 이벤트 수신기(1212)로 지시한다. ErItem은 (순서가 매겨진) MonItem의 각 링을 유지하여, 모든 모니터링이 적절히 제거되도록 하는 데, 이 때 이벤트 수신기는 다이(die)한다.
ErItem은 또한 분배 카테고리의 모든 모니터링의 트랙을 유지한다. 이것을 행하는 방법은 이후에 설명된다.
ErItem이 (클래스 메모리에 의해 처리된) 고속 메모리로부터 할당된 객체이므로, ErItem은 메모리로의 포인터를 유지하고, 이로부터 ErItem이 할당되고, ErItem이 파괴될 시에는 메모리를 복귀시킬 수 있다.
이벤트 발생기(1202 내지 1206)와 같은 각 이벤트 발생기는 MonItem의 링을 유지하는 데, 여기서 링의 각 링크는 이벤트의 소스로서의 이벤트 발생기에 의한 모니터링에 대응한다. 따라서, 이벤트 발생기(1202)에 대해, MonItem(1228, 1234 및 1238)은 화살표(1266, 1268 및 1270)로 표시된 링에 포함된다. 이벤트 발생기(1204)에 대해, MonItem(1230 및 1236)은 화살표(1272 및 1274)로 표시된 링에 포함된다. 이벤트 발생기(1206)에 대해, MonItem(1232)은 화살표(1276)로 표시된 "링"에 포함된다.
각 이벤트 발생기는 또한 이벤트 핸들러로의 포인터를 유지하여 이벤트의 배치를 진행한다. 더욱이, 그것은 이벤트 발생기가 속하는 분배 카테고리를 나타내는 DistCat형의 멤버를 갖는다.
상술한 바와 같이, MonItem은 어떤 이벤트 수신기로의 하나의 이벤트 발생기에 대한 하나 이상의 모니터링을 나타낸다. 상기로부터 나타나 있듯이, MonItem은2개의 링의 멤버인 데, (수신기의 우선 순위에 따라 순서가 매겨진) 한 링은 이벤트 발생기에 속하고, (순서가 매겨지지 않은) 다른 하나의 링은 모니터링 이벤트 수신기에 대응하는 ErItem에 속한다. 따라서, 일예로서, MonItem(1228)은 이벤트 발생기(1202)에 속하는 링(1266, 1268, 1270)의 멤버, 및 이벤트 수신기(1208)에 대응하는 ErItem(1216)에 속하는 링(1248, 1250, 1252)의 멤버이다.
각 MonItem은 그의 ErItem으로의 포인터를 유지하여, MonItem의 ErItem 링으로부터 고속 언링크(unlink)하고, 분배 리스트를 구축할 시에 이벤트 수신기를 찾는다. 따라서, MonItem(1228, 1230 및 1232)은 공통 화살표(1278)로 표시된 ErItem(1216)으로의 포인터를 유지한다. MonItem(1234 및 1236)은 공통 화살표(1280)로 표시된 ErItem(1218)으로의 포인터를 유지하고, MonItem(1238)은 공통 화살표(1282)로 표시된 ErItem(1220)으로의 포인터를 유지한다. 각 MonItem은 또한 제각기 화살표(1260, 1262 및 1264)로 표시된 이벤트 발생기(1202, 1204 및 1206)로의 포인터를 포함하여, MonItem의 발생기의 링으로부터 고속 언링크한다. 분배 리스트의 고속 구축을 위해, MonItem은 또한 모니터링된 이벤트 수신기의 우선 순위를 포함한다.
MonItem은 (클래스 메모리에 의해 처리되는) 고속 메모리로부터 할당된 객체이므로, MonItem은 또한 그들이 할당되고, 그들이 파괴될 시에 메모리를 복귀시키는 메모리로의 포인터를 유지한다.
MonItem은 하나의 발생기로부터 하나의 수신기까지 이벤트를 위해 행해진 하나 이상의 모니터링을 나타낸다. MonItem 객체가 나타내는 어느 정도 많은 모니터링의 트랙을 유지하기 위해, MonItem 객체는 기준 카운터를 포함한다.
이벤트 핸들러는 모든 모니터링의 트랙을 유지하는 구조를 보유한 이벤트 처리 메카니즘에서의 중앙 객체이다. DistCatTree는 이벤트 핸들러의 멤버이고, 이러한 이벤트 핸들러에 의해 모니터링이 작성될 시에 분배 카테고리 또는 이벤트 발생기에 대응하는 ErItem을 찾기 위해 사용된다. 어떤 ErItem도 발견되지 않으면, 이벤트 핸들러는 하나의 모니터링을 작성시켜 그것을 DistCatTree내에 삽입한다.
이벤트 핸들러는 배치되지만 분배되지 않는 모든 이벤트의 링을 유지하는데, 즉 이벤트는 이벤트 수신기로 분배되도록 대기한다. 이벤트 수신기가 다이(die)할 때, 그것은 이벤트를 수신할 수 없다. 그래서, 이러한 수신기를 위해 작성된 MonItem은 더 이상 사용되지 않는다. 그러나, MonItem은 삭제될 수 없는 데, 그 이유는 MonItem에 지시하는 모니터 객체가 아직 존재할 수 있기 때문이다. MonItem은 각각의 잡(job) 종료 시에 스캔되는 "데드(dead)" MonItem의 리스트로 이동되며, 이때 제로의 기준 카운트를 갖는 MonItem는 언링크되어 삭제된다.
이러한 상황은 수신기가 다이할 시에 ErItem에 대한 상황과 거의 동일하다. ErItem은 즉시 파괴될 수 없는 데, 그 이유는 사용자가 ErItem을 기준으로 하는 모니터 객체를 가질 수 있기 때문이다. 또한 ErItem을 기준으로 하는 분배 리스트가 존재할 수 있다. 분배 리스트에 따른 문제를 해결하기 위해, 수신기로의 ErItem 포인터는 수신기가 다이할 시에 0으로 세트되고, ErItem은 그때 어느 이벤트를 더 이상 수신기로 전송하지 않는다. 각각의 잡 종료 시에, 수신기 포인터에 따른 모든 ErItem은 제로와 동일하고, "데드" ErItem의 리스트로 이동된다. 이러한 리스트는각각의 잡 종료 시에 스캔되고, 이 때 제로의 기준 카운트에 따른 ErItem는 언링크되어 삭제된다.
이벤트 객체는 이벤트 수신기로 전달되는 발생된 이벤트의 소프트웨어이다. 이벤트는 이벤트가 배치된 이벤트 발생기로의 포인터, 및 DistItems를 포함하는 분배 리스트를 유지한다. 분배 리스트는 이벤트가 배치될 시에 구축되고, 각 DistItem는 ErItem으로의 포인터를 포함한다. 분배 리스트는 ErItem 이벤트 수신기의 우선 순위에 따른 순서로 매겨진다. 각 이벤트는 또한 이벤트 태그(tag)를 포함한다.
분배 리스트는 각 이벤트에 대해 구축되며, 이때 각 이벤트가 배치된다. 분배 리스트는 이벤트 핸들러에 의해 구축되는 데, 이러한 이벤트 핸들러는 이벤트 태그를 정합하는 MonItem 및 ErItem을 찾는 내부 구조를 스캔한다. 분배 리스트는 ErItem으로의 포인터를 포함하는 각각의 DistItem의 단일 링크된 리스트인 데, 이러한 ErItem은 분배 시에 이벤트를 그의 이벤트 수신기로 전송한다.
분배 리스트를 구축하기 위해, 이벤트를 배치한 이벤트 발생기의 분배 카테고리에 대응하는 ErItem의 링이 발견되어야 한다. 이러한 링은 DistCatTree에서의 노드에 의해 유지된다. 어떤 링도 발견되지 않으면, 버려질 수 있는(삭제될 수 있는) 이벤트에 대한 모니터링이 존재하지 않는다.
또한, 이벤트 발생기를 위해 행해진 모니터링을 나타내는 MonItem의 링을 필요로 한다. 이러한 링은 이벤트 발생기에 의해 유지된다.
아래에서 er-ring 및 mon-ring이라 부르는 이러한 2개의 링은 그때 스캔되고, 멤버는 배치된 이벤트의 태그에 정합되면서, 2개의 링이 이벤트 수신기의 우선 순위에 따른 순서로 매겨지게 한다.
스캐닝은 정합 MonItem을 위한 mon-ring을 스캔함으로써 개시한다. 발견될 시에, er-ring은 현재의 ErItem이 MonItem에 의해 지시될 때까지 스텝된다. 모든 정합 ErItem은 분배 리스트로 수집되면서 이를 실행한다. 그 후, MonItem에 의해 지시된 ErItem은 분배 리스트상에 놓여지고, er-ring 포인터는 한 단계씩 스텝되어, 이벤트가 수신기로 두 번 분배되는 것을 방지한다. 상술한 프로세스는 2개의 링이 완전히 스캔될 때까지 반복된다. 분배 리스트는 이제 완성되고, 이벤트로 제공된다.
각 배치된 이벤트는 분배를 기다리는 링 상에 놓여진다. 분배 자신은 아주 간단한 데, 그 이유는, 각 이벤트가 자신의 분배 리스트을 반송(Carry)하여, 분배가 다음의 단계로 감소되기 때문이다. 이벤트- 링 상의 각 이벤트에 대해, 이벤트는 제거되어, 그의 분배 리스트 상의 모든 수신기로 분배된다. 각 이벤트-전달간에서, eventKilled 플래그는 최종 수신기가 killEvent에 따른 분배를 정지시키는 지 체크되어야 하며, 그 경우에 분배는 다음 이벤트를 계속한다.
상술한 바와 같이, ErItem은 분배 카테고리에 대한 모니터링의 트랙을 유지하고, MonItem은 개별적인 이벤트 발생기에 대한 모니터링의 트랙을 유지한다. 이것은 비트의 어레이를 유지함으로써 행해지는 데, 여기서 각 비트는 하나의 이벤트 태그에 대응한다. 비트는, 모니터링이 작성될 시에 세트되고, 모니터링이 파괴될 시에 소거된다. 이벤트 태그는 2개의 구성 요소, 즉, 부분(part) 및 색인(index)으로 구성되는 데, 여기서, 부분은 도 19에서의 비트 어레이(0, 1, 2, 3)의 부분을 나타내고, 색인은 세트되는 대응 부분의 어느 비트를 나타낸다.
예컨대, 이벤트 태그(0,9), (0,257) 및 (2,65)은 도 19에서의 비트 어레이에 정합한다.
이벤트 태그의 색인 구성 요소의 최하위 비트가 항상 세트된다는 것에 주목해야 한다. 그것은 모든 이벤트의 모니터링이 항시 정합하여야 하기 때문이다. 예컨대, 모든 이벤트에 대한 모니터링이 도 19로부터의 비트 어레이에 부가된다면, 모든 부분의 최종 비트는 세트될 수 있다(도 20 참조).
따라서, 이벤트에 이벤트 태그를 구성할 시에는 이들을 시퀀스(0,5), (0,9), . . .(0,231+1), (1,3), (1,5), . . .(1,231+1), (2,3), (2,5), . . .(2,231+1), (3,3), (3,5), . . .(3,231+1)로부터 선택하도록 해야 한다. 그러나, 이벤트 태그는 또한 하나의 정수를 독립 변수(argument)로 취하고, 맵핑0->(0,5), 1->(0,9), 2->(0,17) 등을 실행하는 구성자를 이용하여 구성될 수 있다. 또한, 부분 0에서 최하위 비트의 바로 우측 비트는 미리 설정된 "데스(death)" 이벤트 태그, 즉 태그(0,3)에 예약되어 있다.
관심이 있는 각 수신기가 이벤트를 처리하기 전에 이벤트의 삭제를 방지하기 위해, 이를 처리하기 위한 메카니즘이 도입된다. 이것은 이벤트-메카니즘 및 스레드 간에 협력하기 위한 것이다. 메카니즘은 이벤트 핸들러 및 스레드에 의해 증가 및 감소되는 카운터를 갖는 이벤트를 토대로 한다. 카운터가 0으로 감소될 시에는자신을 삭제한다. 이벤트 블록에서, 배치된 이벤트의 이벤트 핸들러의 링으로부터 분배될 다음 이벤트를 인출할 시에 증가가 행해진다. 이벤트가 관심을 둔 모든 수신기로 분배된 직후에는 감소가 행해진다. 어떤 스레드도 이벤트 카운터를 증가시키지 않으면, 이벤트는 자신을 삭제한다.
이벤트 수신기가 파괴될 때, 대응하는 ErItem을 파괴할 수 없는 데, 그 이유는 ErItem에 지시하는 DistItem이 존재할 수 있기 때문이다. 또한, ErItem에 지시하는 모니터 객체도 존재할 수 있다. 이벤트 발생기가 파괴될 때, MonItem의 리스트를 삭제할 수 없는 데, 그 이유는 MonItem에 지시하는 모니터 객체가 존재할 수 있기 때문이다.
이러한 두 케이스를 처리하기 위해, 데드(dead) 선언된 객체의 2개의 리스트, DeadErList 및 DeadMonItemList가 있는 데, 이것은 객체가 더 이상 사용 중이지 않지만, 어떤 다른 객체로 참조될 수 있기 때문에 삭제될 수 없다는 것을 의미한다. DeadErList는 이벤트 수신기를 파괴시킨 ErItem으로의 포인터를 포함하고, DeadMonItemList는 이벤트 발생기를 파괴시키고, 어떤 모니터 객체로 여전히 참조되는 모든 MonItem를 포함하는 링이다.
클린업(cleanup)은 각각의 잡 종료 시에 수행되고, 다음의 단계를 포함한다.
먼저, DeadErList 상에서 각 ErItem에 대한 MonItem의 링에서는 각 MonItem을 삭제하고, 이의 기준 카운트는 제로이고, 또한 그것을 DeadMonItemList에 놓는다.
그 후, DeadMonItemList는 제로와 동일한 기준 카운트를 갖는 모든 MonItem을 언링크 및 삭제하는 동안에 스텝된다.
최종으로, DeadErList는 제로와 동일한 기준 카운트를 갖는 모든 ErItem을 언링크 및 삭제하는 동안에 스텝된다.

Claims (28)

  1. 프로세스에서 내부 실행 스레드를 관리하는 시스템으로서,
    상기 실행 스레드는 발생된 내부 또는 외부 인시던트에 응답하여 이벤트 발생 함수(1202 내지 1206)에 의해 발생되는 프로세스 내부 이벤트 메시지에 의해 구동되고,
    상기 내부 이벤트 메시지는 우선 순위를 갖는 이벤트 수신 스레드(1208 내지 1212)로 분배되며,
    상기 분배는 상기 이벤트 발생 함수의 분배 카테고리를 토대로 해서 이벤트 처리 함수에 의해 제어되고, 그러한 내부 메시지에 관심을 갖고 그의 발생의 모니터링을 유발시키는 이벤트 수신 스레드에 대해서만 수행되며,
    각 분배 카테고리에 대해서는,
    다수의 이벤트 수신 스레드,
    어떤 이벤트 수신 스레드로의 하나의 이벤트 발생 함수에 대한 하나 이상의 모니터링을 표시하는 다수의 제 1 엔티티(entity)(1228 내지 1238),
    분배 카테고리의 이벤트 발생 함수에 대한 모니터링을 표시하고, 제각기, 이벤트 수신 스레드를 모니터링한 제 1 엔티티(MonItem) 모두의 리스트를 갖는 다수의 제 2 엔티티(1216 내지 1220),
    상기 제 2 엔티티(1216 내지 1220)의 리스트에 의해 분배 카테고리를 모니터한 모든 이벤트 수신 스레드의 트랙을 유지하는 하나의 제 3 엔티티(1214), 및
    제각기 상기 제 1 엔티티(1228 내지 1238)의 리스트를 유지하는 다수의 이벤트 발생 함수가 존재하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  2. 제 1 항에 있어서,
    각 제 1 엔티티는 상기 이벤트 발생 함수로의 포인터, 및 상기 이벤트 수신 스레드의 우선 순위에 관한 정보를 유지하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  3. 제 1 항 또는 제 2 항에 있어서,
    각 제 2 엔티티는 하나 이상의 제 1 엔티티(1228 내지 1238)에 의해 지시되고, 이벤트 수신 스레드로의 포인터를 유지하여 분배된 이벤트 메시지를 상기 포인터로 전송하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  4. 제 3 항에 있어서,
    상기 제 2 엔티티(1216 내지 1220)의 상기 제 3 엔티티 리스트는 상기 이벤트 수신 스레드를 지시하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  5. 제 4 항에 있어서,
    각 이벤트 발생 함수는 이벤트의 전송을 위해 이벤트 처리 함수로의 포인터를 유지하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  6. 제 5 항에 있어서,
    상기 이벤트 수신 스레드는 각 우선 순위 지시와 관련되고, 프로세스의 실행동안, 상기 제 2 엔티티의 상기 제 3 엔티티 리스트는 현재의 이벤트 수신 스레드 우선 순위에 따른 순서로 되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  7. 제 5 항에 있어서,
    상기 제 2 엔티티(1216 내지 1220)는 모니터링이 이전에 행해지지 않은 이벤트 수신 스레드에 대한 모니터링을 작성할 시에 작성되고, 그 후, 상기 제 2 엔티티(1216 내지 1220)는 상기 제 3 엔티티(1214)에 속하는 제 2 엔티티(1216 내지 1220)의 리스트로 도입되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  8. 제 5 항에 있어서,
    각 제 2 엔티티는 상기 제 2 엔티티(1216 내지 1220)의 제 3 엔티티(1214)리스트로부터의 신속한 제거를 가능하게 하기 위해 상기 제 3 엔티티(1214)로의 포인터를 갖는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  9. 제 5 항에 있어서,
    상기 제 2 엔티티(1216 내지 1220)로의 상기 제 1 엔티티(1228 내지 1238)의 포인터는 상기 제 1 엔티티(1228 내지 1238)의 상기 제 2 엔티티(1216 내지 1220)리스트로부터의 신속한 제거를 가능하게 하기 위해, 및 분배 리스트를 구축하기 위한 이벤트 수신 스레드를 발견하기 위해 유지되며, 이벤트 발생 함수로의 제 1 엔티티의 포인터는 제 1 엔티티(1228 내지 1238)의 이벤트 발생 함수의 리스트로부터의 신속한 제거를 가능하게 하기 위해 있는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  10. 제 5 항에 있어서,
    상기 제 1 엔티티(1228 내지 1238)는 고속 메모리로부터 할당된 객체이고, 그들이 할당되고, 그들이 제거될 시에 메모리를 복귀시키는 상기 메모리로의 포인터를 유지하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  11. 제 5 항에 있어서,
    상기 제 3 엔티티(1214)는 모니터링이 작성될 시에 이벤트 발생 함수 또는 분배 카테고리에 대응하는 상기 제 2 엔티티(1216 내지 1220)를 발견하도록 상기 이벤트 처리 함수에 의해 이용되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  12. 제 5 항에 있어서,
    상기 이벤트 처리 함수는, 배치되지만, 분배되지 않는 모든 이벤트, 즉, 상기 이벤트 수신 스레드로 분배되도록 대기하는 이벤트의 리스트를 유지하는 것을특징으로 하는 내부 실행 스레드 관리 시스템.
  13. 제 5 항에 있어서,
    각 제 1 엔티티(1228 내지 1238)는, 그것이 나타내는 모니터링을 등록하기 위한 기준 카운터를 포함하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  14. 제 13 항에 있어서,
    기준 카운트가 제로인 제 1 엔티티(1228 내지 1238)를 제거하여 삭제할 시에, 상기 제 1 엔티티(1228 내지 1238)는 프로세스에서 잡의 종료 시에 스캔되는 사용 불가의 제 1 엔티티의 리스트로 이동되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  15. 제 5 항에 있어서,
    상기 이벤트 수신 스레드가 사용 불가로 되고, 상기 제 2 엔티티도 더 이상어느 이벤트를 상기 이벤트 수신 스레드로 전송하지 않을 시에, 상기 이벤트 수신 스레드로의 제 2 엔티티(1216 내지 1220)의 포인터는 0으로 설정되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  16. 제 15 항에 있어서,
    각 제 2 엔티티는, 그것이 나타내는 모니터링을 등록하기 위한 기준 카운터를 포함하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  17. 제 16 항에 있어서,
    상기 프로세스에서 잡의 종료 시에, 이벤트 수신 스레드로의 포인터가 제로로 설정된 모든 제 2 엔티티(1216 내지 1220)는, 사용 불가의 제 2 엔티티(1216 내지 1220)의 리스트로 이동되고, 기준 카운트가 제로인 제 2 엔티티(1216 내지 1220)가 상기 리스트로부터 제거되어 삭제될 시에, 상기 리스트는 각각의 잡 종료시에 스캔되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  18. 제 5 항에 있어서,
    상기 제 2 엔티티(1216 내지 1220)는, 고속 메모리로부터 할당된 객체이고, 그들이 할당되고, 그들이 파괴될 시에 메모리를 복귀시키는 상기 메모리로의 포인터를 유지하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  19. 제 5 항에 있어서,
    이벤트 수신 스레드로 전달되는 발생된 이벤트의 소프트웨어 표시(Event)는 제각기 상기 이벤트가 배치된 이벤트 발생 함수로의 포인터, 및 하나의 이벤트를 하나의 이벤트 수신 스레드로의 분배를 나타내는 분배 항목(DistItem)을 포함하는 분배 리스트를 유지하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  20. 제 19 항에 있어서,
    상기 분배 리스트는 상기 이벤트가 배치될 때에 구축되고, 각 분배 항목은 제 2 엔티티(1216 내지 1220)로의 포인터를 포함하며, 상기 분배 리스트는 상기 제 2 엔티티(1216 내지 1220)의 이벤트 수신 스레드의 우선 순위에 따른 순서로 되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  21. 제 19 항에 있어서,
    각 이벤트 표시는 어느 이벤트 발생 함수가 그것을 배치할 수 있는 지에 무관하게 한 형태의 이벤트를 나타내는 이벤트 태그를 포함하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  22. 제 21 항에 있어서,
    상기 분배 리스트는, 상기 이벤트의 이벤트 태그와 정합하는 제 1 엔티티(1228 내지 1238) 및 제 2 엔티티(1216 내지 1220)를 발견하기 위한 프로세스의 내부 구조를 스캔함으로써 상기 이벤트 처리 함수에 의해 구축되는 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  23. 제 21 항에 있어서,
    분배 카테고리에 대한 모니터링의 트랙을 유지하는 상기 제 2 엔티티(1216 내지 1220) 및 개별적인 이벤트 발생 함수에 대한 모니터링의 트랙을 유지하는 상기 제 1 엔티티(1228 내지 1238)는 비트의 어레이에 의해 실행되고, 여기서 각 비트는 하나의 이벤트 태그에 대응하고, 상기 비트는, 모니터링이 작성될 때에 설정되고, 그들이 종료될 때에 소거되며, 각 이벤트 태그는 2개의 구성 요소로 구성되는 데, 하나는 비트 어레이의 일부를 표시하고, 다른 하나는 대응 부분에서 어느 비트가 설정되는 가를 나타내는 인덱스인 것을 특징으로 하는 내부 실행 스레드 관리 시스템.
  24. 제 5 항에 따른 시스템에서의 방법에 있어서,
    관심이 있는 각 이벤트 수신 스레드가 이벤트를 처리하기 전에 이벤트의 삭제를 방지하기 위해, 상기 이벤트 처리 함수 및 스레드에 의해 각 이벤트와 관련된 카운터를 증가 및 감소시키는 단계를 포함하는 데, 상기 카운터는, 그것이 0으로 감소될 때에 그 자체를 삭제하지만, 상기 이벤트 처리 함수의 배치된 이벤트의 리스트로부터 분배되는 다음 하나인 이벤트를 인출(fetch)할 때에 증가를 실행하며, 상기 이벤트가 관심이 있는 모든 이벤트 수신 스레드로 분배된 직후에 감소를 실행하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템에서의 방법.
  25. 제 19 항에 따른 시스템에서의 방법에 있어서,
    각각의 잡(job) 후에 제 1 및 제 2 엔티티를 삭제하기 위해,
    상기 사용 불가의 제 2 엔티티의 리스트(deadErList)상의 각 제 2 엔티티(1216 내지 1220)에 대해, 그의 제 1 엔티티(1228 내지 1238)의 리스트를 식별하고, 기준 카운트가 제로인 각 제 1 엔티티를 삭제하고, 그렇지 않다면, 상기 사용 불가의 제 1 엔티티의 리스트상에 각 제 1 엔티티를 위치시키는 단계,
    상기 사용 불가의 제 1 엔티티의 리스트상에 기준 카운트가 제로인 모든 엔티티를 식별하여, 상기 모든 엔티티를 제거 및 삭제하는 단계, 및
    상기 사용 불가의 제 2 엔티티의 리스트상에 기준 카운트가 제로인 모든 엔티티를 식별하여, 상기 모든 엔티티를 제거 및 삭제하는 단계를 포함하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템에서의 방법.
  26. 제 20 항에 따른 시스템에서의 방법에 있어서,
    분배 리스트를 구축하기 위해,
    상기 이벤트를 배치한 상기 이벤트 발생 함수의 분배 카테고리에 대응하는 제 2 엔티티(1216 내지 1220)의 리스트를 식별하는 단계,
    상기 이벤트 발생 함수에 대해 행해진 모니터링을 표시하는 상기 제 1 엔티티(1228 내지 1238)의 리스트를 식별하는 단계, 및
    이와 같이 식별된 2개의 리스트를 스캔하면서, 그들의 멤버를 상기 배치된 이벤트의 태그와 정합하는 단계를 포함하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템에서의 방법.
  27. 제 26 항에 있어서,
    상기 스캔은, 정합한 제 1 엔티티(1228 내지 1238)를 위한 제 1 엔티티의 리스트를 스캔하는 단계,
    발견될 때, 상기 발견된 제 1 엔티티(1228 내지 1238)에 의해 지시된 현재의 제 2 엔티티(1216 내지 1220)를 발견하기 위한 제 2 엔티티의 리스트를 스캔하면서, 정합한 모든 제 2 엔티티(1216 내지 1220)를 상기 분배 리스트에 수집하고, 각 정합한 엔티티에 대해, 상기 제 2 엔티티의 리스트의 포인터를 1 단계 진행시켜, 상기 이벤트가 상기 이벤트 수신 스레드로 2번 분배되는 것을 방지하는 단계,
    양 리스트가 완전히 스캔될 때까지 반복하는 단계, 및
    이와 같이 완성된 상기 분배 리스트를 상기 이벤트에 제공하는 단계를 포함하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템에서의 방법.
  28. 제 27 항에 있어서,
    상기 분배는, 각 배치된 이벤트를 분배 대기 리스트상에 위치시키는 단계,
    상기 리스트상의 각 이벤트를 제거하여, 이를 상기 이벤트의 분배 리스트상의 모든 이벤트 수신 스레드에 분배시키는 단계, 및
    각 이벤트 전송 사이에서 최후 이벤트 수신 스레드가 분배를 정지했는지를 체크하는 단계를 포함하는 것을 특징으로 하는 내부 실행 스레드 관리 시스템에서의 방법.
KR1019970703853A 1994-12-09 1995-12-08 내부실행스레드관리시스템및그의방법 KR100421797B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE9404294A SE9404294D0 (sv) 1994-12-09 1994-12-09 sätt och anordning vid telekommunikation
SE9404294-2 1994-12-09

Publications (2)

Publication Number Publication Date
KR987000610A KR987000610A (ko) 1998-03-30
KR100421797B1 true KR100421797B1 (ko) 2004-05-20

Family

ID=20396280

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1019970703853A KR100421797B1 (ko) 1994-12-09 1995-12-08 내부실행스레드관리시스템및그의방법

Country Status (14)

Country Link
US (1) US5961584A (ko)
EP (1) EP0796462B1 (ko)
JP (1) JPH10510641A (ko)
KR (1) KR100421797B1 (ko)
CN (1) CN1096027C (ko)
AT (1) ATE223083T1 (ko)
AU (1) AU695271B2 (ko)
BR (1) BR9509892A (ko)
CA (1) CA2206835A1 (ko)
DE (1) DE69527978T2 (ko)
FI (1) FI972406A (ko)
NO (1) NO972596L (ko)
SE (1) SE9404294D0 (ko)
WO (1) WO1996018148A1 (ko)

Families Citing this family (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10320216A (ja) * 1997-05-14 1998-12-04 Sony Corp コンピュータ読み取り可能な記録媒体
JP3883647B2 (ja) * 1997-06-10 2007-02-21 インターナショナル・ビジネス・マシーンズ・コーポレーション メッセージ処理方法、メッセージ処理装置及びメッセージ処理を制御するプログラムを格納する記憶媒体
EP0926908A1 (en) * 1997-12-24 1999-06-30 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Timeout handler in a service control point
US6094663A (en) * 1998-03-31 2000-07-25 Apple Computer, Inc. Method and apparatus for implementing atomic queues
US7216348B1 (en) * 1999-01-05 2007-05-08 Net2Phone, Inc. Method and apparatus for dynamically balancing call flow workloads in a telecommunications system
US6920475B1 (en) * 1999-04-23 2005-07-19 Oracle International Corporation Communication architecture for distributed computing environment
US6505382B1 (en) 1999-05-14 2003-01-14 Apple Computer, Inc. Hinge apparatus with cam mechanism
US6604125B1 (en) 1999-09-24 2003-08-05 Sun Microsystems, Inc. Mechanism for enabling a thread unaware or non thread safe application to be executed safely in a multi-threaded environment
US6701367B1 (en) 1999-09-24 2004-03-02 Sun Microsystems, Inc. Mechanism for enabling customized session managers to interact with a network server
US6766349B1 (en) 1999-09-24 2004-07-20 Sun Microsystems, Inc. Mechanism for obtaining a thread from, and returning a thread to, a thread pool without attaching and detaching
US6629142B1 (en) 1999-09-24 2003-09-30 Sun Microsystems, Inc. Mechanism for optimizing processing of client requests
US6542920B1 (en) * 1999-09-24 2003-04-01 Sun Microsystems, Inc. Mechanism for implementing multiple thread pools in a computer system to optimize system performance
US6895584B1 (en) 1999-09-24 2005-05-17 Sun Microsystems, Inc. Mechanism for evaluating requests prior to disposition in a multi-threaded environment
US6493741B1 (en) 1999-10-01 2002-12-10 Compaq Information Technologies Group, L.P. Method and apparatus to quiesce a portion of a simultaneous multithreaded central processing unit
US6823524B1 (en) * 1999-10-13 2004-11-23 Avaya Technology Corp. System and method for managing the distribution of events in a data processing system
US6671795B1 (en) * 2000-01-21 2003-12-30 Intel Corporation Method and apparatus for pausing execution in a processor or the like
US6951018B2 (en) * 2000-05-30 2005-09-27 Sun Microsystems, Inc. Method and apparatus for efficiently tracking monitors
US6918114B2 (en) * 2001-04-05 2005-07-12 International Business Machines Corporation Method, apparatus, and program to keep a JVM running during the shutdown process of a Java based server executing daemon threads
US6892331B2 (en) * 2002-01-17 2005-05-10 International Business Machines Corporation Method and system for error detection in a managed application environment
US7694304B2 (en) * 2003-08-28 2010-04-06 Mips Technologies, Inc. Mechanisms for dynamic configuration of virtual processor resources
US7376954B2 (en) * 2003-08-28 2008-05-20 Mips Technologies, Inc. Mechanisms for assuring quality of service for programs executing on a multithreaded processor
US9032404B2 (en) 2003-08-28 2015-05-12 Mips Technologies, Inc. Preemptive multitasking employing software emulation of directed exceptions in a multithreading processor
US7594089B2 (en) * 2003-08-28 2009-09-22 Mips Technologies, Inc. Smart memory based synchronization controller for a multi-threaded multiprocessor SoC
US7849297B2 (en) 2003-08-28 2010-12-07 Mips Technologies, Inc. Software emulation of directed exceptions in a multithreading processor
US7836450B2 (en) 2003-08-28 2010-11-16 Mips Technologies, Inc. Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts
US7870553B2 (en) 2003-08-28 2011-01-11 Mips Technologies, Inc. Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts
US7711931B2 (en) * 2003-08-28 2010-05-04 Mips Technologies, Inc. Synchronized storage providing multiple synchronization semantics
US7418585B2 (en) * 2003-08-28 2008-08-26 Mips Technologies, Inc. Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts
US20050066302A1 (en) * 2003-09-22 2005-03-24 Codito Technologies Private Limited Method and system for minimizing thread switching overheads and memory usage in multithreaded processing using floating threads
US7451444B2 (en) * 2003-09-30 2008-11-11 Sas Institute Inc. Computer-implemented system and method for managing service agents
US7278133B2 (en) * 2004-07-23 2007-10-02 Ntt Docomo, Inc. Index-based parameter access and software for using the same
US20060143256A1 (en) 2004-12-28 2006-06-29 Galin Galchev Cache region concept
US7552153B2 (en) * 2004-12-28 2009-06-23 Sap Ag Virtual machine monitoring using shared memory
US7971001B2 (en) 2004-12-28 2011-06-28 Sap Ag Least recently used eviction implementation
US8204931B2 (en) 2004-12-28 2012-06-19 Sap Ag Session management within a multi-tiered enterprise network
US7694065B2 (en) 2004-12-28 2010-04-06 Sap Ag Distributed cache architecture
US7933947B2 (en) * 2004-12-28 2011-04-26 Sap Ag Connection manager that supports failover protection
US7500133B2 (en) * 2004-12-28 2009-03-03 Sap Ag Connection manager for handling message oriented protocol-based requests
US7539821B2 (en) 2004-12-28 2009-05-26 Sap Ag First in first out eviction implementation
US7672949B2 (en) * 2004-12-28 2010-03-02 Sap Ag Connection manager having a common dispatcher for heterogeneous software suites
KR100645537B1 (ko) * 2005-02-07 2006-11-14 삼성전자주식회사 안정적인 패킷 포워딩을 위한 동적인 큐 관리방법 및 이를위한 네트워크 프로세서의 구성요소
US7577657B2 (en) * 2005-03-18 2009-08-18 Microsoft Corporation System and method for updating objects in a multi-threaded computing environment
US8255912B2 (en) * 2005-04-13 2012-08-28 Qualcomm Incorporated Techniques for setting events in a multi-threaded system
US8589562B2 (en) 2005-04-29 2013-11-19 Sap Ag Flexible failover configuration
US7689660B2 (en) * 2005-06-09 2010-03-30 Sap Ag Application server architecture
US7966412B2 (en) 2005-07-19 2011-06-21 Sap Ag System and method for a pluggable protocol handler
US7793299B2 (en) * 2005-08-30 2010-09-07 International Business Machines Corporation System and method for scheduling tasks for execution
US8707323B2 (en) 2005-12-30 2014-04-22 Sap Ag Load balancing algorithm for servicing client requests
EP2030112A2 (en) * 2006-06-06 2009-03-04 Siemens Energy & Automation, Inc. Runtime extension framework
US20090172007A1 (en) * 2007-12-31 2009-07-02 Jonathan Ding Implementing applications with a data model comprising content, thread and category
US8032716B2 (en) * 2008-02-26 2011-10-04 International Business Machines Corporation System, method and computer program product for providing a new quiesce state
US8849631B2 (en) * 2008-05-13 2014-09-30 International Business Machines Corporation Protocol independent telephony call lifecycle management scheme
US8572617B2 (en) * 2009-07-21 2013-10-29 Sas Institute Inc. Processor-implemented systems and methods for event handling
US8769211B2 (en) * 2009-12-22 2014-07-01 Intel Corporation Monitoring thread synchronization in a distributed cache
CN101980167B (zh) * 2010-10-19 2013-02-06 上海富士施乐有限公司 一种任务状态机管理机制运行的方法
US9513961B1 (en) * 2014-04-02 2016-12-06 Google Inc. Monitoring application loading
US9256477B2 (en) * 2014-05-29 2016-02-09 Netapp, Inc. Lockless waterfall thread communication
US9396089B2 (en) 2014-05-30 2016-07-19 Apple Inc. Activity tracing diagnostic systems and methods
US9619012B2 (en) * 2014-05-30 2017-04-11 Apple Inc. Power level control using power assertion requests
CN105094967B (zh) * 2015-06-26 2019-04-16 小米科技有限责任公司 进程运行方法及装置
DE102016200777A1 (de) * 2016-01-21 2017-07-27 Robert Bosch Gmbh Verfahren und Vorrichtung zum Überwachen und Kontrollieren quasi-paralleler Ausführungsstränge in einem ereignisorientierten Betriebssystem
CN106598751B (zh) * 2016-10-31 2020-02-07 武汉斗鱼网络科技有限公司 通过事件总线分发事件的方法及系统
CN116737670B (zh) * 2023-08-11 2023-11-17 英诺达(成都)电子科技有限公司 Upf文件的删除方法、装置、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63208948A (ja) * 1987-02-26 1988-08-30 Toshiba Corp マルチプロセツサシステムにおけるタスクスケジユ−リング方式
WO1993011485A1 (en) * 1991-11-26 1993-06-10 KLAUSTRUP, Edel, Kirstine Method for ordering events in a parallel data processing system
EP0547991A2 (en) * 1991-12-18 1993-06-23 International Business Machines Corporation Adaptive method for starting tasks in a multi-tasking operating system
US5305455A (en) * 1990-12-21 1994-04-19 International Business Machines Corp. Per thread exception management for multitasking multithreaded operating system
JPH06324888A (ja) * 1993-05-10 1994-11-25 Hitachi Ltd スケジューリングシステム

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0381655A3 (en) * 1989-01-31 1992-12-02 International Business Machines Corporation Method for synchronizing the dispatching of tasks among multitasking operating systems
US5057996A (en) * 1989-06-29 1991-10-15 Digital Equipment Corporation Waitable object creation system and method in an object based computer operating system
ATE167582T1 (de) * 1989-09-08 1998-07-15 Digital Equipment Corp Privatspeicher für fäden in einem multifaden digitalen datenverarbeitungssystem
US5377191A (en) * 1990-10-26 1994-12-27 Data General Corporation Network communication system
US5247675A (en) * 1991-08-09 1993-09-21 International Business Machines Corporation Preemptive and non-preemptive scheduling and execution of program threads in a multitasking operating system
US5630128A (en) * 1991-08-09 1997-05-13 International Business Machines Corporation Controlled scheduling of program threads in a multitasking operating system
EP0537721B1 (en) * 1991-10-15 1998-11-25 Hewlett-Packard Company Hardware-configured operating system kernel for a multitasking processor
US5517636A (en) * 1992-01-07 1996-05-14 Unisys Corporation Platform independent data communication system and method
SE500940C2 (sv) * 1993-02-10 1994-10-03 Ellemtel Utvecklings Ab Sätt och system för att i ett distribuerat operativsystem demontera en kedja av sammanlänkade processer
WO1994027216A1 (en) * 1993-05-14 1994-11-24 Massachusetts Institute Of Technology Multiprocessor coupling system with integrated compile and run time scheduling for parallelism
SE502733C2 (sv) * 1993-06-11 1995-12-18 Ellemtel Utvecklings Ab Sätt att undvika ej önskvärd interferens mellan tjänster i ett telekommunikationssystem
US5421013A (en) * 1993-07-08 1995-05-30 Park City Group, Inc. Agent-based multithreading application programming interface
WO1997018661A1 (en) * 1995-11-13 1997-05-22 Answersoft, Inc. Intelligent information routing system and method
US6247675B1 (en) * 1999-05-18 2001-06-19 Four Paws Products, Ltd. Display hanger for a dog leash

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63208948A (ja) * 1987-02-26 1988-08-30 Toshiba Corp マルチプロセツサシステムにおけるタスクスケジユ−リング方式
US5305455A (en) * 1990-12-21 1994-04-19 International Business Machines Corp. Per thread exception management for multitasking multithreaded operating system
WO1993011485A1 (en) * 1991-11-26 1993-06-10 KLAUSTRUP, Edel, Kirstine Method for ordering events in a parallel data processing system
EP0547991A2 (en) * 1991-12-18 1993-06-23 International Business Machines Corporation Adaptive method for starting tasks in a multi-tasking operating system
JPH06324888A (ja) * 1993-05-10 1994-11-25 Hitachi Ltd スケジューリングシステム

Also Published As

Publication number Publication date
EP0796462A1 (en) 1997-09-24
SE9404294D0 (sv) 1994-12-09
FI972406A0 (fi) 1997-06-06
BR9509892A (pt) 1997-12-30
AU695271B2 (en) 1998-08-13
ATE223083T1 (de) 2002-09-15
DE69527978D1 (de) 2002-10-02
DE69527978T2 (de) 2003-01-09
NO972596D0 (no) 1997-06-06
NO972596L (no) 1997-07-17
EP0796462B1 (en) 2002-08-28
AU4276996A (en) 1996-06-26
MX9703999A (es) 1997-09-30
FI972406A (fi) 1997-08-05
CN1169192A (zh) 1997-12-31
CN1096027C (zh) 2002-12-11
US5961584A (en) 1999-10-05
KR987000610A (ko) 1998-03-30
WO1996018148A1 (en) 1996-06-13
CA2206835A1 (en) 1996-06-13
JPH10510641A (ja) 1998-10-13

Similar Documents

Publication Publication Date Title
KR100421797B1 (ko) 내부실행스레드관리시스템및그의방법
JP3691515B2 (ja) オペレーティングシステムにおけるイベント分配装置及び方法
US5303369A (en) Scheduling system for multiprocessor operating system
CN105472042B (zh) Web端控制的消息中间件系统及其数据传送方法
JP3782477B2 (ja) オペレーティングシステムのシステム管理のためのイベントアーキテクチャ
EP0644484A2 (en) Pre-emptive multi-tasking with co-operative groups of tasks
CN106156939A (zh) 基于作业流的分布式调度系统及应用方法
CN113971519B (zh) 一种机器人调度方法、装置、电子设备和存储介质
CN107066339A (zh) 分布式作业管理器及分布式作业管理方法
US7036124B1 (en) Computer resource management for competing processes
US7950011B2 (en) Leveraging advanced queues to implement event based job scheduling
EP0862113A2 (en) Autonomous agent architecture
EP0787396A1 (en) Parallel execution of requests in osi agents
US6504913B1 (en) Call handling mechanism
US20020021774A1 (en) Dispatcher configurable linking of software elements
MXPA97003999A (en) A system to manage internal filaments of execuc
CN113141387B (zh) 业务订阅方法、装置及系统
JP2000267960A (ja) プロセス間のパケット通信方法及びパケット通信装置
Srivastava et al. Controlling multi thread execution using single thread event loop
Baglietto et al. Analysis of design patterns for composite telco services
CN115617541A (zh) 通信方法及事件中枢调度系统
CN115437804A (zh) 消息服务处理方法、装置、设备及存储介质
CN115617543A (zh) 一种基于iros的话题消息订阅和处理方法
KR100442599B1 (ko) 교환 시스템에서 워크스테이션의 분산 객체를 이용한메시지 처리 장치 및 방법
KR100282412B1 (ko) 기지국 관리 시스템에서 큐 구조 및 다수의 프로세서간 큐 운용방법

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20080225

Year of fee payment: 5

LAPS Lapse due to unpaid annual fee