KR101571908B1 - Ｓｉｐ 및 ｓｄｐ 프로토콜을 커스텀화하는 사용자 동시 실행 루틴 인터페이스 - Google Patents

Abstract

BASIC 프로그램과, SIP 및 SDP 데이터 (예컨대)가 수정될 수 있는 시스템 내의 포인트 간의 함수형 인터페이스를 구현하도록 동시 실행 루틴을 이용하는 방법이 제공된다. 이 동시 실행 루틴 인터페이스는 최종 사용자의 관점에서 직관적이고, 시스템 설계자의 관점에서 실시간 효율적이고 유연하며, 단단히 결합된 동시 실행 루틴 인터페이스로부터 생성하는 바람직하지 않은 부작용으로부터 시스템을 보호하면서 최종 사용자에게 큰 융통성을 부여하는 사용하기 쉬운 방식으로 사용자 커스텀화 SIP 및 SDP 수정을 제공하기 위해 적용된다.

Description

ＳＩＰ 및 ＳＤＰ 프로토콜을 커스텀화하는 사용자 동시 실행 루틴 인터페이스{A USER CO-ROUTINE INTERFACE FOR CUSTOMIZING SIP AND SDP PROTOCOLS}

이 출원은 2007년 8월 8일자로 출원된 미국 가출원 제60/964,027호의 이권을 청구한다.

본 발명은 원격 통신 시스템에 관한 것이다. 특히, 본 발명은 원격 통신 시스템에서의 동시 실행 루틴(co-routines)의 이용에 관한 것이다.

오늘날의 원격 통신 시스템은 매우 빠른 속도로 범위와 복잡성 면에서 계속 성장하고 있다. 이런 성장의 인에이블러(enablers) 중 하나는 저 비용의 메모리 및 처리 전력의 가용성인데, 이는 결과적으로 SIP (Session Initiation Protocol) 및 SDP (Session Description Protocol)와 같은 차세대 원격 통신 프로토콜의 개발을 촉진하였다. 이들 미래 지향적 프로토콜은 ASCII (American Standard Code for Information Interchange)-기반하고, 확장 가능하며, 초기 프로토콜보다 더 인간 판독 가능한데, 여기서, 실행 시에 머신 효율은 프로그래머 생산성보다 더 높게 평가되었다.

이들 새로운 프로토콜은 구(older) 프로토콜 보다 지원하는 원격 통신 서비스에 관해 훨씬 많은 정보를 운반하고, 시스템을 특정 애플리케이션에 맞출 시에 많은 융통성은 매우 특정한 방식으로 프로토콜 메시지 내의 데이터를 수정할 능력으로부터 일어난다. SIP 및 SDP와 같은 프로토콜이 ASCII에 기반하므로, 데이터는 최종 사용자, 특히, 네트워크 엔지니어링 및 계획의 책임이 있는 기술자에 의해 수정하기에 적합하다. 과거에는, "복잡한 이진 기반" 프로토콜의 이용은 이와 같은 커스텀화를 구현하기 위해 제조자에 의해 엔지니어링 디자인을 필요로 하였다.

일부 원격 통신 시스템은 전통적으로 특정 애플리케이션에 대한 선택적인 통합 BASIC (Beginner's All-purpose Symbolic Instruction Code) 해석 프로그램(interpreter)을 내장하였다. 이 시스템 내에서 독립적으로 실행하는 스케줄링된 프로세스로서, BASIC 프로그램은 이 시스템 내의 CTI (Computer-Telephony-Interface) 요소로부터 프로세스 간(inter-process) 메시지를 송수신하여, 외부 호스트 컴퓨터의 사용을 필요로 하는 특수화 애플리케이션에 대한 호 처리를 제어한다. 액세스가 또한 BASIC에서 일부 OS (Operating System) 제어에 제공되어, 제조자가 출시된 소프트웨어에 대한 버그 픽스(bug fixes)를 구현하도록 하였다. 이들 제조자-제공 BASIC 프로그램은, 이런 문제를 정정할 새로운 소프트웨어 패키지가 출시될 때까지 어떤 타입의 버그의 증상을 완화한다.

BASIC은 특히 ASCII 캐릭터의 처리 문자열(processing strings)에 잘 맞는 사용하기 쉬운 고 레벨 언어이므로, 최종 사용자 기술자에 의해서나 또는 제조자에 의해서 SIP 및 SDP 메시지 데이터의 커스텀화 수정을 구현하기 위해 이것의 사용을 고려하는 것은 당연하다. 유용한 수정의 일례는, 고 트래픽 주기 동안에 네트워크 부하를 감소시키기 위해 시각(time-of-day)에 따라 SDP "offer" 내에서 데이터를 변경하는 것이다. 이것은 SDP 프로토콜이 미디어 세션이 필요로 하는 비트 레이트에 관계된 정보를 운반하기 때문에 작업한다.

도 1을 참조하면, BASIC 프로세스(10)와 다른 시스템 프로세스(20) 간의 상호 작용 방법은 BASIC이 시스템 스케줄러(5)에 의해 스케줄되는 독립 실행 프로세스이고, 프로세스 간 메시지(IPMs)(30)를 시스템의 다른 요소로 송수신하는 것이다. 이와 같은 방법은 원격 통신 프로토콜 처리와 같은 애플리케이션에 적용될 시에는 곤란하고 비효율적이다. 정보를 BASIC 프로세스(10)로 송신할 필요가 있는 어떤 실시간 시스템 소프트웨어(20)는 IPM(30)을 BASIC 프로세스(10)에 송신하여, 아직 다른 실시간 이벤트 입력을 액셉트할 동안 응답을 기다린다.

아직 다른 이벤트 입력을 액셉트할 동안 응답을 기다릴 요구 조건은 원격 통신 시스템이 데이터를 실시간으로 처리해야 한다는 사실에서 생기고, BASIC으로부터의 응답은 BASIC이 독립적으로 스케줄된 프로세스로서 실행할 경우에 상당히 지연될 수 있다. 더욱 간단한 인터페이스는, BASIC이 간단한 함수 호출(function call)로서, 처리를 원하는 정확한 지점에서 정렬하여(in-line) 인보크(invoke)되도록 한다. 이것은 또한 스케줄링 및 IPMs와 관련된 처리 오버헤드(overhead)를 회피하게 한다.

본 발명은 BASIC 프로그램과, SIP 및 SDP 데이터 (예컨대)가 수정될 수 있는 시스템 내의 포인트 간의 함수형 인터페이스(function-like interface)를 구현하도록 동시 실행 루틴을 이용하는 방법을 포함한다.

본 발명의 방법은 동시 실행 루틴를 이용하여, 단단히 결합된 동시 실행 루틴 인터페이스로부터 생성하는 바람직하지 않은 부작용(side-effects)으로부터 시스템을 보호하면서 최종 사용자에게 큰 융통성을 부여하는 사용하기 쉬운 방식으로 사용자 커스텀화 SIP 및 SDP 수정을 제공한다.

도 1은 컴퓨터 시스템에서 BASIC 프로세스와 다른 프로세스 간에 통신하는 통상의 방법을 도시한 것이다.
도 2는 통상의 서브루틴 호출 메카니즘의 처리 다이어그램을 도시한 것이다.
도 3은 동시 실행 호출 메카니즘의 처리 다이어그램을 도시한 것이다.
도 4는 본 발명의 콘텍스트 관리 처리의 흐름도를 도시한 것이다.
도 5는 본 발명의 콜백 방법의 처리 다이어그램을 도시한 것이다.

동시 실행 루틴(Co-Routines)

보통, 함수 호출(function calls)은 계층적 방식(hierarchical way)으로 행해진다(도 2). 계층 "A" (41)의 최상부에서의 루틴은 어떤 동작을 실행하도록 상기 계층에서 낮은 루틴 "B" (42)를 호출한다. "B"가 완료하면, 그것은 "B"가 호출된 "A" 내의 포인트에서 "A"로 복귀한다. 나중에, "A"는 다시 "B"를 호출할 수 있다. "B"는 상기 계층에서 더 낮은 루틴 "C" (43)를 호출할 수 있지만, 궁극적으로 호출된 각 낮은 루틴은 그의 함수를 완료하여, 상기 계층에서 보다 높은 호출자로 복귀한다.

동시 실행 루틴은 본 기술 분야에서 공지된 도 2의 서브루틴 메카니즘을 일반화(generalization)한 것이다. Donald Knuth, Fundamental Algorithms, Third Edition. Addison-Wesley, 1997. ISBN 0-201-89683-4. Section 1.4.2: Coroutines, pp.193-200, 및 컴퓨터 과학 문학에서의 수많은 다른 참고 문헌을 참조한다. 서브루틴과는 대조적으로, 동시 실행 루틴은 2개의 루틴 "A" 및 "B"이 서로 완전 대칭 방식으로 호출하는 함수 호출의 특정 형식이다 (도 3). 실시간 프로그램 "A" (51)에서 넌 실시간 프로그램 "B" (52)으로의 호출은 그것이 "A"를 최종 호출한 "B" 내의 포인트에서 "B"를 재개한다. 그리고 나서, "B"가 "A"를 호출하면, "A"는 그것이 "B"를 최종 호출한 "A" 내의 포인트에서 재개한다. 함수 호출의 이들 특정 형식은 종종 "calls(호출)"보다는 "yields(양도)"라 불리워지며, "A"는 "B"로 양도되고(대체되고), 그 역으로도 양도된다.

본 발명에서, 도 3에서의 루틴 "A" (51) 및 "B" (52)의 역할은 제각기 원격 통신 시스템 (53)의 호출 처리 소프트웨어 및 BASIC 프로그램에 의해 행해진다. 도 3에서, 실제로 루틴 "A" 및 루틴 "B" 간에 매우 밀접한 관계가 있음을 알 수 있다.

통상적으로, 동시 실행 루틴의 개념은, 보통, Macintosh^TM 컴퓨터에 대한 Apple의 오리지널 운영 체제 (OS)와 같은 "협력적 멀티태스킹(co-operative multitasking)" 시스템에서 약간 제한된 애플리케이션을 가졌다. 이들 타입의 애플리케이션에서, 루틴 "A" 및 루틴 "B"의 양방이 이들 루틴 간의 상당한 상호 작용 및 밀접한 관계로 인해 시스템 프로그래머에 의해 제공되는 것이 관례이다. 대조적으로, 본 발명은, 루틴 "A"이 제품의 중요한 부분으로서 원격 통신 시스템 (53)의 제조자에 의해 제공되지만, 루틴 "B" (BASIC 프로그램)는 개별적으로, 나중에 아마도 네트워크 엔지니어링 및 계획의 책임이 있는 고객의 기술자에 의해 기록되는 방법을 포함한다. 이 BASIC 프로그램은 이때 어떤 다른 BASIC 프로그램과 동일한 방식으로 적재되고 실행되지만, 초기에 기술된 맞춤 서비스(tailoring services)를 제공하기 위해 본 발명의 동시 실행 루틴 인터페이스를 통해 시스템 (53)에 결합된다.

본 발명의 목적 중 하나는 작업하는 동시 실행 루틴(working co-routine) 관계로의 2개의 상이한 프로그래밍 환경의 이런 결합이 달성되는 방법을 제시하는 것이다.

보통 BASIC 해석 프로그램에 의해 제공되는 프로그래밍 환경은 특히 프로그램 개발 단계 동안에 사용자의 관점(perspective)에서 상당히 상호 작용한다. 사용자 (이 경우에는 프로그래머)는 프로그램 명령문(program statements)을 입력하고, 전체 프로그램이나 그것의 보다 작은 세그먼트를 실행하며, 중간 결과를 조사하고, 정정하여 다시 시도할 수 있다. 궁극적으로, 완전한, 가능하게는 버그없는 BASIC 프로그램이 생성한다. 이런 프로세스 동안, 프로그래머와 BASIC 간에 계속적인 상호 작용(continual interplay)이 존재한다. 프로그래머는 단말기(54) 상에 데이터를 입력하고; BASIC은 단말기 출력 및 가능하게는 에러 메시지로 응답한다.

그러나, BASIC 프로그램이 상술한 동시 실행 루틴 인터페이스에서 루틴 "B"의 역할을 하면, 그것은 단말기 입력과 같은 민감성 넌 실시간 보조 구성 요소에 대해 프롬프트(prompt)하고, 에러 메시지를 발행하며, 사용자 응답을 기다리고, 또는 실행을 스톨(stall)하는 어떤 기능을 실행시키는 것이 허용되지 않아야 한다. 실시간 환경에서 시스템 소프트웨어로부터 동시 실행 루틴으로 호출하면, BASIC 프로그램(52)은 본질적으로 순수한 계산(pure computation)으로 제한되어야 한다. 예컨대, BASIC 프로그램이 INPUT 명령문을 포함하고, 실시간 시스템 프로세스로부터 동시 실행 루틴으로서 실행되었으면, 이 실시간 프로세스는 INPUT 명령문을 만족시킬 단말기 입력을 기다리는 그 포인트에서 실행을 중지시킨다. 적절한 때에 이벤트를 처리할 책임이 있는 실시간 프로세스의 실행의 중지는 시스템 불능에 이르게 한다.

그래서, 본 발명의 다른 목적은 BASIC 프로그램의 환경이 이들 위험한 부작용을 방지하도록 동시 실행 루틴으로 이용될 시에 변경될 수 있는 방법을 제시하기 위한 것이다.

BASIC 해석 프로그램

바람직한 실시예에서, BASIC 해석 프로그램(56)은 루틴 "B"이 기록되는 프로그래밍 환경으로 추정되지만, 그것이 실행되는 환경은 아니다. 궁극적으로, 양방의 루틴 "A" 및 루틴 "B"은 프로세서(57a) 및 프로세서(57b) 각각에서 실행하는 머신 코드의 형식으로 동작한다. 루틴 "A"은 C 프로그래밍 언어 또는 다른 컴파일 프로그래밍 언어로 기록되어, 제조자에 의해 제공된 원격 통신 시스템 소프트웨어의 부분이 되도록 컴파일되어 링크된다. 마찬가지로, BASIC 해석 프로그램(56) 그 자체는 C 또는 다른 컴파일 언어로 기록될 수 있다. 양방의 경우에, 루틴 "A" 및 BASIC 해석 프로그램(56)의 부분들은 바람직하게는 속도 및 효율을 위해 어셈블리 언어로 기록된 부분을 포함하는데, 그 이유는 어셈블리 언어는 거의 바로 머신 언어로 변환하기 때문이다. BASIC 해석 프로그램이 사용자의 BASIC 프로그램을 어떻게 처리하는지를 고 레벨로 간단히 기술할 필요가 있다. 컴파일러 및 해석 프로그램의 이면의 상세 개념은 당업자에게 공지되어 있어, 여기서 다루어지지 않을 것이다.

컴파일러와는 대조적으로, BASIC 해석 프로그램(56)은 BASIC 프로그램을 머신 언어로 변환하지 않아, 나중에 그 머신 코드를 실행한다. 대신에, BASIC 해석 프로그램(56)은 사용자의 BASIC 프로그램을 데이터로서 판독하고, 그 데이터에 의해 호출된 동작을 점진적으로 실행한다. BASIC 해석 프로그램은 바람직하게는, 실행을 스트림라인(streamline)하기 위해 편성된 단축형(abbreviated form)으로 사용자의 BASIC 프로그램을 내부적으로 나타냄으로써 프로세서 오버헤드를 최소화하는 단계를 취한다. 그러나, 사용자의 BASIC 프로그램은 BASIC 해석 프로그램이 BASIC 해석 프로그램 내에 이미 제공된 머신 코드의 적절한 시퀀스를 선택하여 실행하도록 하는 역할을 한다. 예컨대, 식 "X + Y"이 나타나면, 해석 프로그램은 머신 코드를 실행시켜, 심벌 X 및 Y에 지정된 값을 가산한다. "PRINT" 명령문이 나타나면, 해석 프로그램은 머신 코드를 실행시켜, 프린트 명령문 내에 지정된 데이터를 단말기(54)로 출력한다. 여기서 중요한 포인트는, 동시 실행 루틴 인터페이스의 관점에서, 루틴 "A" 및 "B"이 바로 보통의 머신 코드이다는 것이다.

본 발명을 기술함에 있어서, 먼저 BASIC 프로그램의 라이터(writer) ("B-라이터")의 관점에서의 동작을 기술하고 나서, 시스템 코드의 라이터 ("A-라이터")의 관점에서의 동작을 기술하는 것이 더 편리할 것이다. 이들 설명에 후속하여, 상세한 동작 방법이 기술될 것이다. 다음의 설명에서, 용어 "콘텍스트"는 프로세스가 실행할 동안에 시행 중인 프로그램 환경 (프로세서 상태, 머신 레지스터 등)을 나타낸다. 도 3에서, 루틴 "A"는 그것이 실행하는 콘텍스트를 가지며, 루틴 "B"는 것이 실행하는 다른 콘텍스트를 갖는다. 그것은 콘텍스트가 어떤 루틴이 실행할 수 있기 전에 달성되어야 함을 당업자에게 공지되어 있다.

B-라이터의 관점에서의 동작

바람직한 실시예에서, BASIC 프로그램은, BASIC 프로그램 내에서 특정 함수 호출, YIELD_{_}TO_{_}SYSTEM(콘텍스트)를 실행함으로써 다른 시스템 구성 요소에 의해 사용하기 위한 동시 실행 루틴으로서 등록되어 있으며, 여기서 '콘텍스트'는 호출의 포인트에서 BASIC 프로그램의 실행 동안에 시행 중인 프로그램 환경을 나타낸다. 여기서는 인수(argument)를 전달하기(passing) 위해 이용되는 시스템 변수 및 상기 함수의 사용을 증명하는 일례의 BASIC 프로그램이다. 이 프로그램은 나중에 주어지는 "C" 프로그램과 함께 작업한다.

이 프로그램에 대한 상세한 라인씩 설명은 나중에 주어질 것이다. 이 점에서, 가장 중요한 개념을 커버하기 위해 개요만이 주어질 것이다.

라인(20)에서의 명령문은 BASIC 프로그램이 실행된 단말기를 자유롭게 하기 위해 BASIC 프로그램(54)을 분리시킨다. 이것이 행해지지 않으면, 단말기는 BASIC 프로그램이 동시 실행 루틴으로서 등록될 시에 나중에 쓸 수 없게 된다. YIELD_{_}TO_{_}SYSTEM(1) 명령문이 실행될 때까지, BASIC 프로그램은 바람직할 수 있는 어떤 타입의 계산을 실행할 수 있다.

라인(40)에서 YIELD_{_}TO_{_}SYSTEM(1)이 먼저 호출되면, 양도(yield)할 이전의 콘텍스트가 존재하지 않아, 동시 실행 루틴 초기화가 실행된다. 현재 BASIC 프로그램 콘텍스트는 콘텍스트 1 (YIELD_{_}TO_{_}SYSTEM()에 대한 인수)로서 저장되어, 본 발명에 따라, BASIC이 나중에 동시 실행 루틴으로서 양도될 시에 바람직하지 않거나 위험한 부작용, 예컨대 민감성 실시간 보조 구성 요소가 일어나는 것을 방지하도록 그 콘텍스트에 대한 어떤 수정이 행해진다. 초기에 기술된 바와 같이, 이들 수정은, BASIC 프로그램이 다른 시스템 프로세스로부터 나중에 동시 실행 루틴으로서 양도될 시에 (도 3에서 루틴 "A"), BASIC 프로그램이, BASIC으로서가 아니라, 실제로 그 프로세스의 부분으로서 여전히 실행하고 있기 때문에 필요로 된다.

본 발명에 따라 민감성 실시간 보조 구성 요소에 대한 수정은 다음과 같다:

ㆍ PRINT 명령문 또는 에러 메시지로부터의 어떤 및 모든 단말기 출력이 무시되고, 나타나지 않는다.

ㆍ PRINT 명령문으로부터 또는 BASIC의 프롬프트로 복귀된 결과로서 단말기 입력을 판독할 어떤 시도는 BASIC로부터 즉각적 퇴장(immediate exit)을 초래하고, 제어는 호출 시스템 프로세스로 다시 양도한다.

ㆍ (바람직한 실시예에서 BASIC 프로그램을 종료하는데 이용되는) BYE 명령문의 실행은 BASIC로부터 즉각적 퇴장을 초래하고, 제어는 호출 시스템 프로세스로 다시 양도한다.

ㆍ 바람직하지 않은 부작용을 가질 수 있는 어떤 다른 특정 애플리케이션 지향 함수는 디스에이블(disable)되어, 실행될 경우에 트랩 가능한(trappable) 에러를 초래한다.

게다가, 이들 콘텍스트 수정의 목적은 BASIC을 동시 실행 루틴으로서 인보크하는 시스템 프로세스가 BASIC 동시 실행 루틴 내에 있을 동안에 자원을 기다리지 않게 하거나 바람직하지 않은 동작을 실행하지 않게 하는 것이다. 동시 실행 루틴은 "순수한 계산"을 실행하기로 되어 있다. 제 1 YIELD_{_}TO_{_}SYSTEM()의 실행에 앞서, BASIC 프로그램은 보통 행하는 어떤 것을 행하는데 자유롭고, YIELD_{_}TO_{_}SYSTEM()이 처음에 실행된 후에 시스템으로의 액세스를 제한하는 콘텍스트 수정만이 시행됨에 주목한다.

이런 초기화 프로세스가 완료되었으면, BASIC은 (이 예에서) 동시 실행 루틴 콘텍스트 1가 사용에 이용 가능한 어떤 잠재적 사용자 (루틴 "A")에 나타낼 플래그를 설정한다. 동시 실행 루틴 인터페이스가 초기화된 후에, BASIC 프로세스는, 동시 실행 루틴으로서 실행할 동안에 BASIC 프로그램 내에서 치명적인 에러가 발생하였거나, 이 프로그램이 명백히 퇴장하도록 요구받은 신호를 수신할 때까지 휴지 상태(dormant state)에 들어간다. 바람직한 실시예에서, 이 신호는 운영 체제 이벤트이지만, 어떤 적절한 신호 수단이 사용된다. BASIC 프로세스는 이 휴지 상태에 들어가, 동시 실행 루틴으로서 양도되기 전에 저장된 콘텍스트로의 어떤 후속 수정을 방지해야 한다.

따라서, 시스템 소프트웨어가 나중에 동시 실행 루틴 인터페이스를 통해 BASIC으로 양도하면, BASIC 프로그램의 콘텍스트는, YIELD_{_}TO_{_}SYSTEM(1) 명령문이 먼저 실행되고, BASIC 프로그램이 동시 실행 루틴으로서 그 포인트에서 끊김없이(seamlessly) 실행을 재개할 시에 바로 그대로일 것이다. 이 시스템 (특히, 시스템 스케줄러)의 나머지까지, 동시 실행 루틴으로서 BASIC로 양도되는 시스템 소프트웨어는 그 자신의 프로세스 내에서 함수 호출을 간단히 실행하며, 오리지널 BASIC 프로세스는 휴지 상태에 있다. 이것은 본 발명에서 중요한 개념이다.

시스템 소프트웨어(루틴 "A")가 BASIC 동시 실행 루틴으로 양도하면, BASIC 프로그램은 라인(40)에서 YIELD_{_}TO_{_}SYSTEM() 함수 호출로부터의 "return"일 것이다. 그 후, 이 프로그램은 "인수 전달하기(passing arguments)" 하에 아래에 기술되는 바와 같이 그것에 전달된 어떤 인수에 액세스하여, 바람직한 어떤 계산을 실행할 수 있다. 그 후, 결과는 복귀된다. 전형적으로, 이 프로그램은 이때 동일한 YIELD_{_}TO_{_}SYSTEM() 함수 호출로 루프백하지만, 이것은 필요치 않다. 이것은 상기 예에서 일어나는 것인데, 그 이유는 라인(30)에서의 "REPEAT" 명령문 및 라인(290)에서의 "UNTIL 0" 명령문이 무한 루프 구성(endless loop construct)을 이루기 때문이다. YIELD_{_}TO_{_}SYSTEM() 함수 호출이 다시 실행되자마자, 그 포인트(루틴 "B")에서의 BASIC 콘텍스트는 이전에 BASIC으로 양도되었던 포인트에서의 시스템 소프트웨어(루틴 "A")로 다시 양도된다. 게다가, 이것은 도 3에 도시되어 있다.

당업자는 상술한 것에 대신하도록 기록될 수 있는 제한되지 않는 수의 가능 BASIC 프로그램이 효율적으로 존재함을 이해할 것이다. 예는 수반된 원리만을 입증하기 위한 것이며, 제한하는 것으로 취해지지 않아야 한다.

인수 전달하기

BASIC 프로그램이 어떤 유용한 데이터 처리를 실행하기 위하여, 루틴 "A"에서 루틴 "B"로 인수를 전후로 전달하는 메카니즘이 분명히 있어야 한다. 이것은 수개의 변수가 정의되는 공유 메모리 영역(58)을 지정함으로써 행해질 수 있다. 루틴 "A"는 적절한 값을 변수 내에 저장할 수 있고, 루틴 "B"는 이때 이들을 검색할 수 있다. 마찬가지로, 루틴 "B"는 결과치를 변수 내에 저장할 수 있고, 루틴 "A"는 이때 이들 결과치를 검색할 수 있다. 바람직한 실시예에서, BASIC 해석 프로그램(56)은 판독 전용 변수, 기록 전용 변수 및 판독-기록 변수의 개념을 지원한다. 협정에 의해, 루틴 "A"는 "B 라이터"가 입력으로서 이용할 수 있는 어떤 변수로 애플리케이션 특정 값을 저장할 것이다. 입력을 전달하고, 결과치를 복귀시키기 위해 동일한 판독-기록 변수를 이용하는 것은, 입력에 대한 변경이 필요치 않을 경우에, 정확한 변경되지 않은 값이 자동으로 복귀되는 이점을 갖는다.

상기에 주어진 예시적 BASIC 프로그램은 이제 상세히 기술된다. 이 프로그램이 본 발명이 제시하는 능력의 특정 사용을 예시하지만, 이런 동시 실행 루틴 인터페이스를 통해 인보크되는 BASIC 프로그램에 의한 데이터 조작의 많은 다른 예들은 당업자에게 생성할 것이다. 따라서, 이 예는 제한하는 것으로 취해지지 않아야 한다.

라인(10)에서, 프로그램은 변수 NEWLINE＄를 뉴스라인 문자(ASCII 20)를 포함하는 열로 설정한다. 이것은 나중에 이용된다. 라인(20)에서, 프로그램은, 프로그램이 나중에 동시 실행 루틴으로서 등록될 시에 단말기(54)가 사용 가능하지 않게 되는 것을 방지하도록 초기화되는 단말기로부터 프로그램을 분리하는 함수를 호출한다. 라인(30)은 라인(30)에서 라인(290)으로 하향 연장하는 무한 루프 구조를 정의한다. 라인(40)은 BASIC이 초기에 (처음에만) 상세히 기술된 콘텍스트 수정을 실행하도록 하여, 시스템으로 다시 양도하고, 동시 실행 루틴으로서 시스템으로부터 후속 호출을 기다린다. 시스템이 BASIC 프로그램을 인보크할 필요가 있으면, 그것은 어떤 입력 파라미터를 설정하여, BASIC으로 다시 양도한다. 이것은 BASIC 프로그램이 라인(50)에서 실행을 재개하도록 한다.

이 포인트에서, 그것은 이런 예시적 BASIC 프로그램의 목적을 재진술하는데 유용하다. 시스템 관리자는 고 트래픽 주기 동안 (예컨대, 08:00 내지 16:59의 시간 주기 동안) 행해진 호출에 대한 SDP 오퍼(offers)를 처리하기를 원함으로써, 더욱 적은 네트워크 자원이 이들 호출에 필요로 되도록 한다. 특히, 관리자는, 08:00 내지 16:59의 시간 동안 SDP 내에 제공된 어떤 코덱 (코더/디코더) 초이스를 삭제하도록 SDP 오퍼 내의 데이터를 변경하기를 원한다. 이것은 결과적으로, 그 시간 주기 동안에 행해진 호출에 대한 데이터 내의 필요한 곳에서 SDP 데이터로부터 "0" 및/또는 "8"을 삭제하게 된다.

라인(50)에서, BASIC 프로그램은 함수 LEFT(TIME＄,2)를 호출한다. 변수 TIME＄는 열(예컨대, "09:23:50")로서 현재 벽 시간을 복귀시키는 시스템 변수이다. LEFT 함수는 이 열의 좌측 2개의 문자를 HOUR＄ 변수로서 추출한다. 라인(60)에서, 시스템 변수 WO_{_}ARG_{_}1는 0으로 설정된다. 협정에 의한 이런 변수는 BASIC에서 시스템으로 다시 전달된 복귀 값 중 하나이다. 그것을 0으로 설정함은, 프로그램이 SDP 조작을 실행하지 않았음을 나타낸다. 나중에 넌-제로(non-zero) 값으로 설정하지 않으면, 이것은 상태 응답으로서 시스템으로 복귀될 것이다. 라인(70)에서, 현재 벽 시간이 08:00와 16:59의 사이에 있는지를 결정하도록 검사가 행해지고, 그 시간 동안에 SDP 조작이 일어날 수 있다. 필요한 시간 주기 내에 있지 않으면, 명령문은 거짓(false) 결과로 평가할 것이고, 제어는 라인(280)으로 스킵 다운(skip down)하여, 거기로부터 라인(290)으로 스킵 다운할 것이다. 라인(290)에서의 UNTIL 0 명령문은 항상 거짓 조건(0은 거짓으로 간주된다)으로 평가하여, 제어가 라인(30)으로 다시 복귀되고 나서, BASIC이 다시 시스템으로 양도하는 라인(40) 상으로 복귀된다. SDP 조작이 일어나지 않으므로, 호출은 오리지널 SDP 오퍼로 진행할 것이다.

그러나, 라인(70)에서 현재 벽 시간이 08:00 내지 16:59 시간 주기 내에 있으면, IF 명령문은 참(true) 결과로 평가할 것이고, 제어는 라인(80)으로 전달될 것이다. 라인(80)에서, 변수 SDP＄ 는 RW_{_}ARG_{_}1＄로 설정된다. 변수 RW_{_}ARG_{_}1＄는 협정에 의해, 동시 실행 루틴이 인보크될 시에 시스템에 의해 BASIC로 전달되는 입력 인수 중 하나이다. 그것은 오리지널 SDP 오퍼 데이터를 나타낸다. 판독-기록 변수이면, 그것은 BASIC 프로그램에 의해 변경되어, 결과로서 시스템으로 다시 복귀될 수 있으며, 이것은 이 경우에 일어나는 바로 그대로이다. 라인(80)에서 SDP＄ 변수 내에 저장된 데이터는 단말기로 프린트될 경우에 다음과 같이 나타난다:

상기에서 각 라인은 ASCII 10 (뉴스라인) 문자로 끝난다. 라인(90)에서, INSTR 함수는 텍스트 "m=audio"에 대한 열을 탐색하고, 발견된 열 내의 문자 위치에 POS1을 설정한다. 라인(100)은 INSTR이 열을 발견하였음을 검사한다 (INSTR은 열이 발견되지 않았을 경우에 0을 복귀시킨다). 열 "m=audio"이 SDP 내에서 발견되지 않았다면, POS1은 0일 것이고, 제어는 라인(270)으로 스킵 다운하여, 궁극적으로 전과 같이 라인(40)으로 다시 스킵 다운한다. 그러나, 열 "m=audio"이 발견되면, 라인(110)으로 이동하여, SDP 오퍼 내에서 열 "RTP/AVP"을 발견하려고 한다. 게다가, 이것이 발견되지 않으면, POS2는 0일 것이고, 라인(120)에서 라인(260)으로 스킵하여, 라인(40)으로 다시 스킵한다. 그러나, "RTP/AVP"이 발견되면, "0" 열을 찾는 라인(130)으로 드롭(drop)한다. 상기 도시된 예시적 SDP에서, 이것은 볼드체

로서 발견될 것이다. SDP에 대한 규칙이 라인의 끝에서도 이 값이 생성하도록 하므로 (여기서, 값 "101"은 예에 놓임), 또한, "0"에 대해 검사하고 나서, SDP 오퍼의 각 라인을 종료시키는 뉴스라인 문자를 검사해야 한다. 이것은 라인(140)에서 검사된다. 라인(150)은 어느 한 방법에 의해 "0"을 발견하였는지를 검사하며, 발견하였다면, 라인(160)은, 오리지널 SDP (LEFT 함수)의 좌측 부분을 "0" 바로 전까지 연쇄시킴으로서 새로운 SDP 오퍼 텍스트를 생성시키며, 오리지널 SDP (RIGHT 함수)의 우측 부분은 "0" 바로 위에서 개시한다. 이것은 SDP 오퍼로부터 "0"을 삭제하는 효과를 갖는다. 마찬가지로, 라인(190 내지 240)은 SDP 오퍼로부터 "8"을 삭제한다. 양방의 경우에, 라인(170 및 230)은 SDP 조작이 성공적인 시스템에 나타내도록 복귀 상태 시스템 변수를 1에 설정한다. 최종으로, 라인(250)에서, 새로운 SDP 오퍼가 시스템으로 다시 전달되도록 판독-기록 변수 RW_{_}ARG_{_}1＄ 내에 다시 저장된다. 그리고 나서, 제어는 라인(40)으로 다시 복귀하고, BASIC은 시스템으로 다시 양도한다. 시스템 소프트웨어 (루틴 "A")는 이제 BASIC 프로그램 (루틴 "B")에 의해 수정되었을 수 있는 SDP 오퍼로 진행할 것이다.

다중 동시 실행 루틴 콘텍스트

상기 예는 YIELD_{_}TO_{_}SYSTEM(1)을 이용한다. 하나 이상의 능동 동시 실행 루틴 콘텍스트가 존재할 수 있다. 예컨대, 시스템 소프트웨어가 협정에 의해 SDP 데이터 수정을 위해 콘텍스트 1을 이용하도록 코드화되면, 이것을 동시 실행 루틴으로서 처리할 BASIC 프로그램은 YIELD_{_}TO_{_}SYSTEM(1)을 이용한다. 콘텍스트 2를 이용하도록 코드화되는 다른 독립 프로세스 (예컨대, SIP 수정 또는 디버거)가 존재할 수 있다. 다른 BASIC 프로그램은 이들 서비스를 위해 어느 이용된 YIELD_{_}TO_{_}SYSTEM(2)를 실행한다.

"A-라이터의" 관점에서의 동작

"A-라이터"는, 초기에 진술된 바와 같이, 제조자에 의해 제공된 원격 통신 시스템 소프트웨어의 부분이 되도록 컴파일되어 링크되는 C 프로그래밍 언어로 시스템 소프트웨어 (루틴 "A")를 기록하는 것으로 추정할 것이다. BASIC 동시 실행 루틴 (루틴 "B")을 인보크하기에 적절한 이 코드 내의 포인트에서, 아래에 주어진 코드 프래그먼트(code fragment)에 도시된 바와 같이 수개의 단계가 취해지지만, 프로세스는 실제로 간단한 함수 호출에 지나지 않는다:

상기 "C" 코드 프래그먼트의 상세한 설명

상기 코드 프래그먼트는 매우 간단하다. 제 1 "if" 명령문은 콘텍스트가 이용 가능한지를 알기 위해 데이터 구조 변수를 검사한다. BASIC 프로그램이 아직 실행되지 않아 그의 YIELD_{_}TO_{_}SYSTEM() 함수를 실행하지 않았다면, 이 변수는 여전히 0일 것이며, BASIC 프로그램에 대한 호출이 행해지지 않을 것이다. BASIC 프로그램이 동시 실행 인터페이스를 초기화하였다면, 이 변수는 0이 아닐 것이고, "if"의 바디(body)는 실행될 것이다.

"context_{_}index"는 BASIC에서 행해진 YIELD_{_}TO_{_}SYSTEM() 함수에 이용된 인수에 동의하도록 1로 설정된다. 다른 BASIC 동시 실행 루틴 실행이 그것을 이용하는 다른 "C" 프로그램과 함께 존재할 수 있으며, 이런 프로그램의 제 2 쌍(second pair)은 협정에 의해 다른 "콘텍스트 인덱스" 값 (예컨대, 2)을 이용하기로 합의했다.

다음 명령문은 BASIC 프로그램이 수정할 수 있는 SDP 열 ("sdp_{_}data")로의 포인터(pointer)에 대한 입력 인수 "rw.str_{_}arg"를 설정한다. 이것이 BASIC에 대한 판독-기록 변수이므로, "max_{_}len" 변수는 얼마나 많은 메모리가 그 열 내에 저장할 시에 이용 가능한지를 BASIC에 나타내도록 설정된다. 이것은 BASIC이 이 열에 할당된 메모리 이상으로 기록하지 못하게 한다. 다음 명령문은 복귀 상태 값을 초기화함으로써, 그것이 BASIC 프로그램이 어떤 이유로 그 값을 설정하지 않을 경우에 TRUE로 디폴트하도록 한다.

그 후, "job_{_}context" 변수는 어떤 넌-제로 값 (이 예에서는 "1")으로 설정된다. 이것은, 막 호출될 bas_{_}context_{_}swap() 함수에, (동시 실행 루틴 초기화가 행해 질 시에) 그것을 처음으로 호출하는 것이 아니라, 이미 실행하는 BASIC 동시 실행 루틴으로 콘텍스트 스왑(context swap)을 간단히 실행하기를 원함을 나타낸다. (BASIC 프로그램이 그의 YIELD_{_}TO_{_}SYSTEM() 함수 호출을 실행하면,

bas_{_}context_{_}swap()는 또한 호출되지만, "job_{_}context" 변수는 처음에는 0이어서, 동시 실행 초기화가 처음에 논의된 바와 같이 실행된다.)

bas_{_}context_{_}swap() 함수는 이제 호출된다. 이것은 최종 실행된 YIELD_{_}TO_{_}SYSTEM() 명령문에 따른 명령문에서 BASIC에 양도하는 콘텍스트 스왑을 실행한다. BASIC은 인수를 인출하고, 그의 처리를 행하여, 그의 결과를 시스템 변수에 저장한다.

BASIC 프로그램이 동일하거나 다른 YIELD_{_}TO_{_}SYSTEM() 명령문을 실행하면, 제어는 이런 C-언어 코드 프래그먼트로 다시 양도되고, bas_{_}context_{_}swap()에 대한 호출이 복귀한다. 그 후, 이런 C 코드 프래그먼트는 시스템 변수로부터 어떤 결과를 픽업(pick up)할 수 있다. 다음 "if" 명령문은, 협정에 의해 BASIC 프로그램이 그의 작업에서 성공적인지를 나타내는데 이용되는 이들 변수 ("wo.int_{_}arg") 중 하나를 검사한다. BASIC 프로그램에 의해 가능하게는 수정되는 변수 "sdp_{_}data"는 이제 C 코드 프래그먼트에 의해 다른 사용자에 이용 가능하다.

BASIC와 "C" 동시 실행 루틴 인수 간의 일치(correspondence)

다음의 테이블은 예시적 C 코드 프래그먼트 및 예시적 BASIC 프로그램의 구조 요소 간의 관계를 도시한 것이다:

주석:

1) 이 열 변수 인수는 어느 한 잡(job)에 의해 판독되거나 기록될 수 있다.

2) 이 정수 인수는 단지 BASIC에 의해 기록될 수 있다.

콘텍스트 스왑 실행

동시 실행 원리, 동시 실행 관계에서 동작하는 C 코드 프래그먼트 및 BASIC 프로그램의 인터페이스 및 특정 예를 초기화할 시에 취해질 단계를 논의한다. 이제, 동시 실행 루틴 콘텍스트 스왑을 실행하고, C와 BASIC 동시 실행 루틴 간에 제어를 전달하는 실제 루틴을 기술한다. 이것은, BASIC이 YIELD_{_}TO_{_}SYSTEM() 함수를 호출하거나, C 코드 프래그먼트가 bas_{_}context_{_}swap() 함수를 호출할 시에 호출되는 공통 코드이다.

이런 코드가 머신 레지스터를 포함하는 전체 프로그램 콘텍스트를 저장하여, 프로그램의 스택 (후입선출(last-in-first-out) 방식으로 액세스되고, 고 레벨 언어로 직접 액세스 가능한 메모리의 영역)을 보존해야 하기 때문에, 이런 코드는 보통 머신 언어로 기록되어야 한다. 콘텍스트 스와핑(swapping)을 더욱 잘 설명하기 위해, 흐름도가 도 4에 주어지고 나서, 그 흐름도를 설명할 것이다.

상술한 바와 같이, 이런 공통 코드는, YIELD_{_}TO_{_}SYSTEM() 함수가 호출될 시에는 BASIC로부터, bas_{_}context_{_}swap() 함수가 호출될 시에는 C 코드 프래그먼트로부터 호출된다. 이런 코드가 호출되는 첫 시간은 BASIC 프로세스에서 실행하는 BASIC 프로그램이 처음 YIELD_{_}TO_{_}SYSTEM()을 호출하는 시기이다. 도 4를 참조하면, 프로세싱은 (101)에서 개시한다. (102)에서, 필요한 모든 잡(job) 콘텍스트 정보는 현재 잡(BASIC)의 스택(59)(도 3) 상에 저장된다. 상술한 바와 같이, 이 스택(59)은 현재 잡 (BASIC)의 정규 동작 중에 이미 저장된 많은 잡 콘텍스트 아이템을 포함하지만, 이런 부가적 정보는 머신 레지스터 및, 정상적으로 저장되지 않은 다른 정보를 포함한다. 전체적으로, 이 정보는 나중에 프로그램을 재개하는데 필요로 되는 모든 것을 포함한다. (103)에서, 이것이 이 코드가 호출된 첫 시간인지를 확인하도록 검사가 행해진다. 첫 시간이어서, (104)에서 계속한다. 단계(104)에서, 바로 저장된 BASIC 프로그램의 환경은, BASIC 프로그램이 상술한 바와 같이 나중에 동시 실행 루틴으로서 인보크될 시에 위험한 부작용을 방지하도록 변경된다. 이런 프로세스는 나중에 더욱 상세히 설명될 것이다. (105)에서, 새로운 스택 영역이 BASIC 프로그램에 대해 설정됨으로써, 어떤 식으로든 저장된 콘텍스트를 방해하지 않고, (106)에서 휴지 상태에 안전하게 들어갈 수 있다. 이것은 중요한데, 그 이유는 저장된 콘텍스트가 나중에 복원될 것이고, 동시 실행 루틴으로서의 정확한 동작이 복원된 콘텍스트가 정확히 동일하지 않을 경우에는 불가능할 것이기 때문이다. 오리지널 BASIC 프로세스는 이제 휴지 상태에 있어, 이 포인트에서 결코 전진하지 않는다.

이제, C 코드 프래그먼트는 bas_{_}context_{_}swap() 함수를 실행함으로써 이 코드를 호출한다.

다시 말하면, (101)에서 개시한다. 정확히 동일한 코드를 실행할지라도, 이호출은 C 코드 프래그먼트를 포함한 시스템 프로세스로부터 나오고, BASIC 프로세스로부터 나오지 않았다. (102)에서, 필요한 모든 잡 콘텍스트 정보는 현재 잡 스택(60) 상에 저장되지만, 이번에는, 그것은 C 코드 프래그먼트를 포함하는 시스템 프로세스의 스택 및 콘텍스트일 것이다. (103)에서의 검사는 이것이 처음 호출되지 않아 (107)에서 계속할 것임을 결정할 것이다. 현재 콘텍스트로의 포인터는 (막 떠나려고 하는 콘텍스트를 의미하는) FROM 포인터로서 양방의 BASIC 및 C 코드 프래그먼트에 액세스 가능한 메모리 영역(58) 내에 저장된다. (108)에서, 이전에 저장된 콘텍스트로의 포인터는 (막 들어가려고 하는 콘텍스트를 의미하는) TO 포인터로서 인출된다. (109)에서, 이전의 콘텍스트는 복원된다. 이것은 BASIC이 초기에 이 코드를 호출하였을 시에 저장된 콘텍스트일 것이다. (110)에서, 이 코드는 복귀할 것이다. 정규 계층 함수는 도 2에 도시된 바와 같이 그것을 호출한 프로그램으로 복귀한다. 그러나, 콘텍스트 스와핑은 결과적으로 도 3에 도시된 바와 같이 동시 실행 루틴으로서 작용하는 이 코드를 생성시킨다. 그래서, (110)에서, 제어는 콘텍스트가 초기에 저장된 BASIC 동시 실행 루틴으로 복귀된다.

BASIC 프로그램은 이제 실행하고, 어떤 포인트에서, 그것은 YIELD_{_}TO_{_}SYSTEM() 함수를 호출할 것이다. 게다가, 이 코드는 (101)에서 호출될 것이다. 게다가, (102)에서, 현재 콘텍스트는 저장될 것이며 (이때에는 BASIC의 콘텍스트), 게다가, (103)에서, 제어는 현재 콘텍스트 포인터를 저장하는 (107)로 전달될 것이다. C 코드 프래그먼트의 저장된 콘텍스트는 (108 및 109)에서 복원될 것이다. (110)에서, 복귀하지만, 다시 호출자로 복귀하지 않지만, 도 3에서와 같이 C 코드 프래그먼트로 복귀할 것이다. 이 때에는 이 코드는 BASIC로부터 호출되지만, C로 복귀된다. 사실상, 도 3에서, 좌측 루틴 "A"를 우측 루틴 "B"과 링크하는 실선 화살표(55)는 이 콘텍스트 스와핑 코드에 대한 호출에 지나지 않으며, C 코드 프래그먼트는 루틴 "A"의 역할을 하고, BASIC 프로그램은 루틴 "B"의 역할을 한다.

BASIC 프로그램의 환경의 변경

본 발명의 다른 목적은 BASIC 프로그램의 환경이 위험한 부작용을 방지하기 위해 동시 실행 루틴으로서 이용될 시에 변경될 수 있는 방법을 제시하는 것으로 상술되었다. 이런 환경은, BASIC 해석 프로그램(56)이 입력/출력을 실행하여, 시스템 자원에 액세스하기 위해 호출하는 함수의 세트에 해당한다. 바람직한 실시예에서, 이들 함수의 모두에 대한 액세스는 간접적이고, "콜백 함수"로서 공지된 것을 이용한다. BASIC 해석 프로그램(56)이 먼저 인보크되면, 그것은 BASIC이 입력/출력 및, 시스템 자원 (도 5에서 "콜백 함수 어드레스의 리스트"(62))으로의 액세스를 위해 이용할 수 있는 함수의 어드레스의 리스트로 전달된다. 그리고 나서, BASIC은, 이 리스트로부터 필요한 함수의 어드레스를 획득하여 그것을 호출함으로써 (도 5) 간접 방식으로 이들 함수를 호출한다. 선택적인 것은 도 2에 도시된 바와 같이 정규 방식으로 간단히 함수를 직접 호출하는 것이다.

콜백 함수를 이용하는 하나의 이점은 플랫폼 독립성(platform independence)인데, 그 이유는 BASIC 해석 프로그램(56)이 플랫폼의 입력/출력 및 시스템 인터페이스 요구 조건의 특성(specifics)에 관련되지 않아, BASIC 언어 그 자체를 배타적으로 처리하는 "순수(pure) 코드"에 머무를 수 있기 때문이다. 그러나, 본 발명에서, 콜백 함수의 이용은 또한, 동시 실행 루틴으로서 실행할 시에 BASIC 프로그램의 환경을 변경하기 위한 매우 유연하고 효율적인 수단을 제공한다. 동시 실행 루틴이 처음 액세스되고, YIELD_{_}TO_{_}SYSTEM()가 처음 호출되면, 도 4에서 콘텍스트 스와핑 코드(104)는 이런 콜백 함수의 리스트를 수정하여, 동시 실행 루틴으로서 실행할 시에 이들 생각된 위험에 대해 새로운 함수 어드레스를 대입한다. 이것은 특정 함수만이 대입될 필요가 있으므로 유연한 방법이다. 그것은 또한 하나의 어드레스의 대입(substitution)이 BASIC 내의 그 함수에 대한 모든 호출을 자동으로 커버하므로 효율적이다. 예컨대, 도 5에서, (63)에서 오리지널 함수 "A"가 단말기 입력을 처리하는 함수이고, 동시 실행 루틴 내에 있을 시에 이 함수를 디스에이블하는 것이 바람직하면, (62)에서 엔트리 "A의 어드레스"는, 단말기 입력을 실행하지 않고, 가능하게는 에러를 보고하는 다른 함수(64)의 어드레스를 포함하도록 변경될 수 있다. 이런 대입이 실행되면, BASIC 해석 프로그램(56)으로부터의 모든 "A로의 함수 호출" (도 5에 도시된 함수 "A"에 대한 2개의 호출이 존재한다)은 새로운 함수 ("함수 A에 대한 교체 코드(alternate code)")를 이용하여 자동으로 시작할 것이다.

콜백 함수를 대입하는 이런 방법이 이용되지 않았다면, 잠재적으로 위험한 함수 호출이 행해지는 BASIC 해석 프로그램 내의 모든 포인트에서, 코드는 그 포인트에서 호출할 어느 함수(오리지널 또는 새로운)를 검사하기 위해 존재해야 한다. 이런 검사는 실행 시간에 프로세서 오버헤드를 초래하여, 실시간 시스템에서 수락할 수 없으며, 에러를 범하기 쉬운데, 그 이유는 함수 호출의 각 발생이 개별적으로 처리되어야 하기 때문이다. 콜백 어드레스의 대입은 동시 실행 루틴 인터페이스가 처음 초기화될 시에 한번만 행해질 필요가 있다.

5: 시스템 스케줄러, 10: BASIC 프로세스, 20: 다른 시스템 프로세스

Claims (15)

1. 실시간 컴퓨터 시스템 내의 데이터를 관리하기 위한 방법으로서,
   하나 이상의 실시간 구성 요소 및 보조 구성 요소를 포함하는 실시간 컴퓨터 시스템 내에 실시간 프로그램을 제공하는 단계와;
   실시간 컴퓨터 시스템 내의 실시간 프로그램과의 동시 실행 루틴으로서 사용하기 위해 넌 실시간 컴퓨터 시스템 내에 넌 실시간 프로그램을 제공하는 단계로서, 넌 실시간 프로그램이 하나 이상의 넌 실시간 데이터 관리 구성 요소 및 보조 구성 요소를 포함하는, 단계와;
   실시간 프로그램의 실시간 소프트웨어 구성 요소와 넌 실시간 프로그램의 넌 실시간 소프트웨어 구성 요소 간에 콘텍스트를 스위치할 실시간 컴퓨터 시스템의 콘텍스트 스와핑 소프트웨어 구성 요소를 제공하는 단계와;
   실시간 프로그램의 보조 구성 요소로서 이용될 수 없는 각각의 넌 실시간 데이터 관리 소프트웨어 구성 요소의 민감성 넌 실시간 보조 구성 요소를 식별하는 단계와;
   민감성 넌 실시간 보조 구성 요소를 실시간 프로그램의 보조 구성 요소로서 이용하기 위한 실시간 환경 보호 보조 구성 요소로 대체하는 단계와;
   실시간 환경에서 실시간 프로그램을 실행하는 단계를 포함하고;
   실시간 프로그램의 실행 동안, 실시간 프로그램이 넌 실시간 프로그램으로 양도하고, 콘텍스트 스와핑 소프트웨어 구성 요소가 실시간 프로그램 환경에서 넌 실시간 프로그램의 실행을 가능하게 하고, 여기서 민감성 넌 실시간 보조 구성 요소를 실시간 환경 보호 보조 구성 요소로 대체하는 단계가 각각의 민감성 넌 실시간 보조 구성 요소를 실시간 환경 보호 보조 구성 요소로 대체하도록 콜백 테이블을 이용하는 단계를 포함하는 것을 특징으로 하는 방법.
2. 제1항에 있어서,
   실행하는 단계 동안, 실시간 프로그램이 정지되거나, 일시 중지되거나 또는 서스펜드되지 않는 것을 특징으로 하는 방법.
3. 제1항에 있어서,
   넌 실시간 프로그램은 실시간 언어 및 환경과 다른 언어 및 환경에서 기록되는 것을 특징으로 방법.
4. 제3항에 있어서,
   실시간 프로그램은 컴파일 언어 및 그의 환경을 이용하여 기록되고 실행되며, 넌 실시간 프로그램은 해석 언어(interpreted language) 및 그의 환경에서 기록되는 것을 특징으로 하는 방법.
5. 제4항에 있어서,
   넌 실시간 프로그램의 해석 언어 및 그의 환경은:
   BASIC 언어 및 그의 해석 프로그램;
   Python 언어 및 그의 해석 프로그램;
   Ruby 언어 및 그의 해석 프로그램;
   Java 언어 및 그의 해석 프로그램; 및
   JavaScript 언어 및 그의 해석 프로그램으로 이루어진 그룹에서 선택되는 것을 특징으로 하는 방법.
6. 제1항에 있어서,
   실시간 프로그램의 컴파일 언어 및 그의 환경은:
   C 언어 및 그의 컴파일러;
   C++ 언어 및 그의 컴파일러;
   C# 언어 및 그의 컴파일러로 이루어진 그룹에서 선택되는 것을 특징으로 하는 방법.
7. 제1항에 있어서,
   실시간 프로그램은 컴퓨터 시스템 종속 어셈블리 언어 및 그의 환경을 이용하여 기록되고 실행되는 것을 특징으로 하는 방법.
8. 제1항에 있어서,
   실시간 프로그램의 실행 동안, 넌 실시간 프로그램이 실시간 프로그램으로 양도하고, 콘텍스트 스와핑 소프트웨어 구성 요소가 실시간 프로그램의 정상 실행을 가능하게 하는 것을 특징으로 하는 방법.
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제

Images