KR101988898B1 - 타스크 상태점검을 통한 타스크 고착상태 복구 방법 - Google Patents

Abstract

본 발명은 작업 스케쥴링의 타스크를 관리하는 방법에 관한 것이다. 본 발명에 따른 타스크 상태점검을 통한 타스크 고착상태 복구 방법은, 작업 스케쥴링의 타스크(Task)들을 식별하는 고유의 아이디(ID)를 기반으로, 상기 타스크들의 동작 상태를 주기적으로 확인하는 타스크 상태점검 단계; 소정시간 이상 제1 상태가 지속되는 타스크에 대하여, 특정 메시지를 메시지 큐(Message queue)에 삽입하는 메시지 삽입 단계; 및 상기 메시지 큐에 근거하여, 상기 특정 메시지가 소정 개수 이상이며 상기 제1 상태인 타스크의 경우, 상기 타스크의 상태를 상기 제1 상태에서 제2 상태로 전환하는 타스크 상태전환 단계;를 포함한다.

Description

타스크 상태점검을 통한 타스크 고착상태 복구 방법{Task Dead Rock Recovery Method through the Task Status Checking}

본 발명은 작업 스케쥴링의 타스크를 관리하는 방법에 관한 것이다.

일반적으로 임베디드 운용소프트웨어에서, Task는 작업 스케쥴링의 가장 기본이 되는 프로그램 실행단위를 의미한다. 작업 스케쥴링이란 CPU를 점유하는 순서를 결정하는 것으로, 작업 스케쥴링에 따라 Task 들이 순차적으로 실행된다. 이러한 Task 들은 실행되기 전에 다음과 같은 상태를 지니고 있다.

A. Ready: 어떠한 자원도 기다리지 않는 대기 상태 [Task is not waiting for any resource] - 이 상태의 Task 들은 정상적인 상태이나, 실행되기 위해서는 CPU의 점유를 계속 기다린다.

B. Pend: Task 동작대기(Blocking) 상태 [The task is blocked due to the unavailability of some resource] - 이 상태의 Task 들은 정상적인 상태로써, 가용한 자원(Resource)이 도착할 경우 실행된다.

C. Delay: Task Sleep 상태 [The task is asleep for some duration] - 이 상태의 Task 들은 정상적인 상태로써 일정 대기시간 이후 실행된다.

D. Suspend: Task가 더 이상 동작 할 수 없는 상태 [The task is unavailable for execution] - 이 상태의 Task들은 실행이 불가능하게 된 비정상적인 상태이다.

E. Stop: Task 동작이 잠시 정지된 상태 [The task is stopped by the debugger] - 이 상태의 Task들은 정상적인 상태이나, 디버깅을 위해 일시적으로 정지된 상태이다.

임베디드 운용소프트웨어의 실행 중에는 이러한 Task 동작상태가 실시간으로 계속 전환되고 발생하게 된다.

이중 Suspend Task의 경우, 상호간의 이벤트 유실, 유효하지 않은 메모리의 접근, 메모리 부족 등과 같은 문제에 따라, Task가 더 이상 동작 할 수 없는 상태로 전이되는 경우로, 반드시 운용소프트웨어를 재실행 하여야만 해당 Task 상태가 정상 복원될 수 있다.

반면, Ready Task의 경우는 정상상태로 볼 수 있다. 그러나, 이더넷 통신을 기반으로 하는 임베디드 시스템들 사이에 실시간 데이터 송신 및 수신 시, 송신 측에서 전송하는 데이터의 전체 사이즈 정보를 포함하는 패킷이 유실되는 경우가 발생하게 되면, 데이터 전체 사이즈의 식별이 불가하게 된다. 그 결과, 수신 측의 운용소프트웨어의 Task가 계속 Ready 상태로 머무르게 된다. 또한, 운용자의 비정상적인 제어 또는 알려지지 않은 원인에 의해 Task 가 계속 Ready 상태로 머무는 경우도 있다.

이에 따라, CPU의 점유를 계속 기다리게 되는 경우가 발생하여, Task 상태가 정상임에도 그 기능을 수행할 수 없게 된다.

따라서, 이와 같은 경우 CPU를 점유 시키고, Ready 상태의 Task를 Pend 상태로 전환시킨다면 해당 기능을 수행할 수 있게 된다.

종래의 임베디드 운용소프웨어 Task 운용은 Task의 상태를 구별하지 않고 운용되어왔다. 따라서, 운용소프트웨어가 원하는 Task를 수행하지 못하는 경우(Task 고착상태)에는 운용소프트웨어가 더 이상 실행될 수 없어, 항상 시스템을 재실행/부팅하여 운용소프트웨어를 다시 초기화 시켜 실행하는 방식으로 운용되어왔다.

이로 인해 많은 시간손실과 잦은 시스템 재부팅으로 인한 시스템열화 등과 같은 문제를 야기 시켜왔다.

본 발명은 전술한 문제 및 다른 문제를 해결하는 것을 목적으로 한다. 또 다른 목적은, Task의 상태를 점검하여 시스템 운용 중에 고착상태에 빠진 Ready Task를 정상상태로 복원하기 위한, 타스크 상태점검을 통한 타스크 고착상태 복구 방법을 제공하는 것을 그 목적으로 한다.

상기 또는 다른 목적을 달성하기 위해 본 발명의 일 측면에 따르면, 작업 스케쥴링의 타스크(Task)들을 식별하는 고유의 아이디(ID)를 기반으로, 상기 타스크들의 동작 상태를 주기적으로 확인하는 타스크 상태점검 단계; 소정시간 이상 제1 상태가 지속되는 타스크에 대하여, 특정 메시지를 메시지 큐(Message queue)에 삽입하는 메시지 삽입 단계; 및 상기 메시지 큐에 근거하여, 상기 특정 메시지가 소정 개수 이상이며 상기 제1 상태인 타스크의 경우, 상기 타스크의 상태를 상기 제1 상태에서 제2 상태로 전환하는 타스크 상태전환 단계;를 포함하는 것을 특징으로 하는 타스크 상태점검을 통한 타스크 고착상태 복구 방법을 제공한다.

실시 예에 있어서, 상기 타스크 상태전환 단계는, 상기 특정 메시지가 상기 소정 개수 미만이며 상기 제1 상태인 타스크의 경우, 상기 타스크의 상태를 상기 제1 상태로 유지시키는 단계;를 포함할 수 있다.

또 다른 실시 예에 있어서, 상기 특정 메시지는, 타임아웃(Timeout) 메시지를 포함할 수 있다.

또 다른 실시 예에 있어서, 상기 제1 상태는, 레디 타스크(Ready Task) 상태일 수 있다.

이때, 상기 제2 상태는, 펜드 타스크(Pend Task) 상태일 수 있다.

본 발명에 따른 타스크 상태점검을 통한 타스크 고착상태 복구 방법의 효과에 대해 설명하면 다음과 같다.

본 발명에 따르면, 이더넷 통신을 기반으로 하는 임베디드 시스템들 사이, 특히, 송신 및 수신 측에서 유실된 데이터에 의해 운용소프트웨어의 Task가 Ready 고착상태가 될 경우 발생할 수 있는 데이터 송신 및 수신(인터페이스) 불가상태 복구 방법을 제안하였다. 또한, 예상치 못한 오류로 인해 임베디드 운용소프트웨어의 Task가 Ready 고착상태가 될 경우 복구 방법을 제안하였다.

본 발명의 실시 예들 중 적어도 하나에 의하면, 데이터 수신측 Task들의 동작상태를 지속적으로 확인하여 비정상적인 상태를 파악 할 수 있다. 이를 통해, 통신상의 데이터 유실로 인한 Ready 상태로 도래 된 Task들을, 운용자의 시스템 재부팅과 같은 직접 제어를 배제하여, 복구를 위한 시간 손실을 최소화 할 수 있게 된다.

따라서, 종래의 기술(Ex. Terminal 내에서 Task Kill 및 Task Create Command 입력)의 한계였던 운용자의 작업 투입을 배제하여, 시스템이 자율적으로 Task 상태를 점검 및 복구 할 수 있게 된다.

또한, 본 발명은, 임베디드 운용소프트웨어에서 이더넷 통신을 기반으로 실시간으로 데이터를 송신 및 수신하는 여러 민간 또는 군 산업분야에 적용될 수 있다.

본 발명의 적용 가능성의 추가적인 범위는 이하의 상세한 설명으로부터 명백해질 것이다. 그러나 본 발명의 사상 및 범위 내에서 다양한 변경 및 수정은 당업자에게 명확하게 이해될 수 있으므로, 상세한 설명 및 본 발명의 바람직한 실시 예와 같은 특정 실시 예는 단지 예시로 주어진 것으로 이해되어야 한다.

도 1은 본 발명에 따른 타스크 상태점검을 통한 타스크 고착상태 복구 방법의 실시 예를 설명하기 위한 개념도이다.
도 2는 본 발명에 따른 타스크 상태점검을 통한 타스크 고착상태 복구 방법의 실시 예를 설명하기 위한 흐름도이다.

이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시 예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소에는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시 예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시 예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시 예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.

본 출원에서, "포함한다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

이하, 첨부된 도면을 참조하여 본 발명을 더욱 상세하게 기술할 것이다. 이하의 설명에서 본 발명의 모든 실시형태가 개시되는 것은 아니다. 본 발명은 매우 다양한 형태로 구현될 수 있으며, 여기에 개시되는 실시형태에 한정되는 것으로 해석되어서는 안 된다. 본 실시형태들은 출원을 위한 법적 요건들을 충족시키기 위해 제공되는 것이다. 동일한 구성요소에는 전체적으로 동일한 참조부호가 사용된다.

도 1은 본 발명에 따른 타스크 상태점검을 통한 타스크 고착상태 복구 방법의 실시 예를 설명하기 위한 개념도이다.

도 1을 참조하면, 모든 Task들은 Task를 식별할 수 있는 고유의 ID를 가지고 있다. 따라서, 이를 기반으로 메모리에 상주 중인 각 Task들의 동작 상태를 주기적으로 확인하는 “Task 상태점검(100)” 단계가 수행될 수 있다.

이어서, 일정시간 이상의 Ready Task의 경우에는, Timeout 메시지를 각 Task 별 Message queue에 삽입하는 “Timeout 메시지 삽입(200)” 단계가 수행될 수 있다.

마지막으로, 각 Task 별로 관리되는 Message queue을 점검하여 N개의 Timeout 메시지를 보유하고 있는 Ready Task를 Pend Task로 전환하는 “Task 상태전환(300)” 단계가 수행될 수 있다.

도 2는 본 발명에 따른 타스크 상태점검을 통한 타스크 고착상태 복구 방법의 실시 예를 설명하기 위한 흐름도이다.

도 2를 참조하면, 시스템 운용 시, “Timer의 Task 상태 점검(100)” 단계를 통해 Task의 상태를 점검할 수 있는 상태를 설정할 수 있다.

이후 “A초 후 Task 상태(200)” 단계를 통해 A초 이후 Task 상태를 점검하게 되며, “Ready 상태(300)” 단계 및 “Pend 상태(400)” 단계로 분기 하게 된다.

본 단계들(300, 400)에서는 Task의 상태가 Ready 혹은 Pend인지 판단 할 수 있으며 “Ready 상태(300)” 단계일 경우, “Message queue에 Timeout message 삽입(500)” 단계로 진입하여, Ready 상태를 식별할 수 있는 Time-stamp로, Timeout message를 Message queue에 삽입한다.

반면, “A초 후 Task 상태(200)” 단계 이후 Task 의 상태가 Pend 이면, “Pend 상태(400)”로 진입하며, Task 상태 점검을 하기 위해 “A초 후 Task 상태(200)” 단계로 다시 진입하게 된다.

“Message queue에 Timeout message 삽입(500)” 단계 이후에는 “N번 이상 도착(600)” 단계로 진입하여 Timeout message가 N번 이상 도착 시 “Pend 상태 전환(700)” 단계로 분기되어, 본 단계에서 Task의 상태를 Pend로 전환한다.

반면, Timeout message가 N번 미만 도착 시, “기존 상태 유지(800)” 단계로 분기되어 현재 Task 상태를 유지하게 된다.

본 발명에 따른 타스크 상태점검을 통한 타스크 고착상태 복구 방법의 효과에 대해 설명하면 다음과 같다.

본 발명에 따르면, 이더넷 통신을 기반으로 하는 임베디드 시스템들 사이, 특히, 송신 및 수신 측에서 유실된 데이터에 의해 운용소프트웨어의 Task가 Ready 고착상태가 될 경우 발생할 수 있는 데이터 송신 및 수신(인터페이스) 불가상태 복구 방법을 제안하였다. 또한, 운용자의 비정상적인 제어 또는 알려지지 않은 원인에 의해 Task 가 계속 Ready 상태로 머무는 경우에 Task 복구 방법을 제안하였다.

본 발명의 실시 예들 중 적어도 하나에 의하면, 데이터 수신측 Task들의 동작상태를 지속적으로 확인하여 비정상적인 상태를 파악 할 수 있다. 이를 통해, 통신상의 데이터 유실로 인한 Ready 상태로 도래 된 Task들을, 운용자의 시스템 재부팅과 같은 직접 제어를 배제하여, 복구를 위한 시간 손실을 최소화 할 수 있게 된다.

따라서, 종래의 기술(Ex. Terminal 내에서 Task Kill 및 Task Create Command 입력)의 한계였던 운용자의 작업 투입을 배제하여, 시스템이 자율적으로 Task 상태를 점검 및 복구 할 수 있게 된다.

또한, 본 발명은, 임베디드 운용소프트웨어를 이용하는 장치를 제어하는 모든 산업분야, 특히, 임베디드 운용소프트웨어에서 이더넷 통신을 기반으로 실시간으로 데이터를 송신 및 수신하는 여러 민간 또는 군 산업분야에 적용될 수 있다.

상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.

Claims (5)

1. 임베디드 운용소프트웨어가 적용된 장치가, 작업 스케쥴링의 타스크(Task)들을 식별하는 고유의 아이디(ID)를 기반으로, 상기 타스크들의 동작 상태를 주기적으로 확인하는 타스크 상태점검 단계;
   상기 임베디드 운용소프트웨어가 적용된 장치가, 제1 상태가 지속되는 타스크에 대하여, 특정 메시지를 일정 시간마다 해당 타스크의 메시지 큐(Message queue)에 삽입하는 메시지 삽입 단계;
   상기 임베디드 운용소프트웨어가 적용된 장치가, 각 타스크 별 메시지 큐를 점검하여 상기 특정 메시지를 보유한 타스크들 각각의 메시지 큐에 삽입된 상기 특정 메시지의 개수를 산출하는 특정 메시지 개수 산출 단계; 및
   상기 임베디드 운용소프트웨어가 적용된 장치가, 산출된 특정 메시지의 개수에 근거하여, 상기 특정 메시지가 소정 개수 이상인 상기 제1 상태의 타스크를 제2 상태의 타스크로 전환하는 타스크 상태전환 단계;를 포함하며,
   상기 제1 상태는,
   자원의 기다림 없이 CPU가 점유되면 실행될 수 있는 상태이며,
   상기 제2 상태는,
   가용한 자원이 있는 경우에 CPU를 점유받아 실행될 수 있는 상태임을 특징으로 하는 타스크 상태점검을 통한 타스크 고착상태 복구 방법.
2. 제1항에 있어서,
   상기 타스크 상태전환 단계는,
   상기 임베디드 운용소프트웨어가 적용된 장치가, 상기 특정 메시지가 소정 개수 미만이며 상기 제1 상태인 타스크의 경우, 상기 타스크의 상태를 상기 제1 상태로 유지시키는 단계;를 포함하는 것을 특징으로 하는 타스크 상태점검을 통한 타스크 고착상태 복구 방법.
3. 제2항에 있어서,
   상기 특정 메시지는, 타임아웃(Timeout) 메시지를 포함하는 것을 특징으로 하는 타스크 상태점검을 통한 타스크 고착상태 복구 방법.
4. 삭제
5. 삭제

Images