實時間運營體制

實時間運營體制 ( 文化語 : 實時間造作體系) 또는 RTOS (← Real Time Operating System )는 實時間應用 프로그램을 위해 開發된 運營體制 이다. 運營體制의 機能中 CPU 時間管理部分에 焦點을 맞추어 設計되었다. 實時間運營體制는 프로그래머가 프로세스 優先順位에 더 많은 制御를 할 수 있게 한다. 應用 프로그램의 優先順位가 시스템 프로그램의 優先順位를 넘어설 수도 있다. 시스템 코드의 臨界區域 을 最少化하였으며, 이를 통하여 應用 프로그램의 處理要請을 定해진 時間 안에 處理해 줄 수 있다.

實時間運營體制의 核心은 應用 프로그램 테스크 處理에 걸리는 時間을 一貫되게 維持할 수 있는 程度에 있다. 處理時間의 變動幅은 지터( jitter )(實際信號와 基準點과의 時間偏差)라 부른다. 京城( hard ) 實時間運營體制와 軟性( soft ) 實時間運營體制로 區分할 수 있으며, 電子가 後者에 비해 지터가 적다. RTOS의 주된 設計目標는 높은 處理率 (throughput)李 아니라, 實時間性能保障 에 있다. 實時間 시스템의 데드라인을 大體로 맞추는 RTOS를 軟性實時間運營體制라 하고, 데드라인을 決定論的 알고리즘 (deterministic algorithm)에 依해 滿足하는 境遇를 京城實時間運營體制라 한다. ^[1]

規模가 큰 實時間運營體制의 初期例는 "制御 프로그램"이었는데, 이는 아메리칸 航空 (American Airlines)과 IBM 이 세이버 (Sabre) 航空豫約 시스템을 위해서 開發한 것이었다.

設計方式 [ 編輯 ]

두 가지 基本的인 設計方式이 存在한다.

이벤트 驅動(event-driven) 方式: 優先順位基盤 스케줄링 또는 先占型 스케줄링 이라고 부른다. 태스크(task) 轉換이 現在遂行中인 태스크보다 높은 優先順位를 갖는 이벤트가 서비스를 要請할 境遇에 일어난다.
時分割(time-sharing) 스케줄링 方式: 클럭 인터럽트나 라운드 로빈 과 같은 週期的인 이벤트가 發生할 때 태스크의 轉換이 일어난다.

嚴密히 말해, 時分割 스케줄링 方式은 實際必要한 것보다 더 자주 태스크 轉換이 일어난다. 하지만 이러한점 德分에 좀 더 자연스럽고, 豫測하기 쉬운 멀티태스킹 을 提供하며, 하나의 프로세스나 한名의 使用者가 裝置를 獨占的으로 使用하는 것과 같은 效果를 提供한다. 때문에 이 方式이 좀 더 나은 멀티태스킹 方式처럼 보일 수 있다.

스케줄링 [ 編輯 ]

傳統的인 設計方式에서, 태스크는 隨行(running), 待機(ready), 블록(blocked)의 세 가지 狀態(state) 中 한 가지 狀態로 存在한다. 大部分의 태스크가 블록狀態이고, 오직 1個의 태스크만 遂行狀態이다. 簡單한 시스템 일수록 待機狀態의 태스크 目錄이 짧으며, 많은 境遇도 2~3個程度이다.

一般的으로 스케줄러 待機 태스크 目錄의 데이터 構造 는 스케줄러의 臨界區域 (CPU의 先占이 禁止되며, 어떠한 境遇에는 모든 인터럽트가 비활성화된다.)에서 消費되는 時間을 最少化할 수 있게 設計 한다. 하지만, 데이터 構造의 選擇은 待機 리스트에 들어갈 수 있는 最大 태스크의 數字에도 左右된다.

萬若大氣目錄에 2~3個程度에 적은 數의 태스크만 存在하는 構造라면, 單純히 二重連結 리스트 構造로 待機目錄을 具現하는 것도 效率的이다. 反面, 通常 적은 數에 태스크만 存在하지만 가끔 그보다 많은 數가 存在하는 境遇라면, 태스크를 實行할 때마다 全體目錄을 뒤져 優先順位가 높은 태스크를 찾는 作業을 反復的으로 하지 않도록 優先順位를 基準으로 미리 整列하거나 높은 優先順位의 태스크를 낮은 優先順位의 태스크보다 먼저 大氣 리스트에 追加할 수 있도록 設計한다. 卽, 待機目錄을 檢索하는 동안 CPU의 先占을 禁止하지 않거나 긴 臨界區域을 작게 나누어야 한다는 意味이다. 이 말은 낮은 優先順位의 태스크를 리스트에 追加하는 동안이라도, 높은 優先順位의 태스크를 待機狀態로 만드는 인터럽트가 發生하면, 높은 優先順位의 태스크를 먼저 大氣目錄에 追加하고 바로 遂行할 수 있도록 한다는 것이다.

새로운 태스크가 生成되면 이 태스크는 一旦大氣狀態가 된다. 스케줄러는 現在遂行中인 태스크 亦是大氣狀態로 變更하고, 두 個의 태스크를 待機狀態 태스크 目錄에 집어 넣는다. 그 後, 가장 優先順位가 높은 태스크를 다시 遂行하는데 이 全體過程에 걸리는 時間을 重要應答時間(critical response time) 或은 플라이백 타임 (flyback time) 이라고 부른다. 잘 設計된 實時間運營體制의 境遇, 새로운 태스크를 待機狀態로 만드는 데 3-20個의 命令語를 使用한다. 또, 가장 높은 優先順位를 가진 待機 태스크를 隨行狀態로 變更하는데 5-30個의 命令語를 使用한다.

高級實時間運營體制에서는 實時間으로 動作하는 태스크들이 實時間으로 動作하지 않는 태스크들과 컴퓨터 資源을 共有한다. 따라서 大氣 리스트는 相當히 길어질 수 있다. 이러한 시스템에서 스케줄러 待機 리스트를 簡單한 連結 리스트 (linked list)로 具現하는 것은 알맞지 않다.

스케줄링 알고리즘 [ 編輯 ]

一般的으로 RTOS에서 使用되는 스케줄링 알고리즘에는 아래와 같은 것이 있다.

協力型 스케줄링 (cooperative scheduling)
先占型 스케줄링 (pre-emptive scheduling)
- 라운드 로빈 스케줄링 (Round-robin scheduling)
- 固定優先順位先占型 스케줄링 (fixed priority pre-emptive scheduling)

태스크 間通信과 資源共有 [ 編輯 ]

멀티태스킹 시스템은 여러 個의 태스크 사이에 共有되는 데이터와 하드웨어 資源을 管理해 주어야 한다. 大部分의 境遇 두 個以上의 태스크가 同時에 같은 데이터나 하드웨어 資源에 接近하는 것은 危險하다. ("危險"하다는 것은 한 태스크가 複數의 데이터를 更新하는 中일 境遇, 結果가 一貫性이 없고 豫測不可能하다는 뜻이다. 다른 태스크가 이 데이터들에 接近해도 되는 時點은 更新이 始作하기 前이나 完全히 終了된 後 뿐이다.) 이 問題를 解決하기 위해서 普通使用되는 3가지 方式을 紹介한다.

一時的인 인터럽트 非活性化 [ 編輯 ]

汎用運營體制 에서는 使用者가 인터럽트 를 마스크(非活性化)하지 못한다. 그 理由는 使用者의 프로그램이 運營體制의 核心資源인 CPU 를 너무 긴 時間 동안 占有하고 있을 수 있기 때문이다. 다시 말해, 現在使用되는 大多數의 CPU들은 使用者 모드 코드가 인터럽트를 비활성화할 수 있는 權限을 附與하지 않는다. 하지만, 많은 임베디드 시스템과 實時間運營體制들은 應用 프로그램이 運營體制의 干涉 없이 시스템 콜 을 效率的으로 使用할 수 있게 하기 위해 커널 모드 에서도 動作할 수 있도록 한다.

單一 프로세서 시스템에서, 萬若應用 프로그램이 現在 커널 모드로 動作하고, 인터럽트를 비활성화할 수 있다면, 大槪 인터럽트 非活性化야말로 두 個以上의 태스크가 同時에 共有資源에 接近하는 것을 막아주는 最高의 技法이다. 인터럽트가 非活性化되어 있는 境遇, 現在 돌고 있는 태스크는 다른 태스크나 인터럽트가 CPU를 制御할 수 없기 때문에 "排他性"을 띠며, 따라서 臨界區域 은 保護 받는다. 태스크가 臨界區域에서 벗어나게 되면, 待機中인 인터럽트가 있다면 實行되도록 인터럽트를 다시 活性化시켜야 한다. 一時的으로 인터럽트를 비활성화하는 것은 臨界區域 의 가장 긴 經路가 인터럽트 待機時間보다 짧은 境遇有效한 戰略이다. 그렇지 않다면 이 方法을 통하여 시스템의 最大 인터럽트 待機時間을 증가시킬 可能性이 있다. 따라서 臨界區域 이 團地 몇 個의 命令語로 이루어졌거나, 反復構文을 包含하지 않은 境遇有效하다고 할 수 있다.

細麻布어 [ 編輯 ]

細麻布어는 잠기거나 풀려있다. 잠겨 있을 때 作業들의 待機는 細麻布어(가 풀리기)를 기다린다. 細麻布어 디자인들이 가지는 問題點들은 잘 알려져 있다: 優先順位逆轉 과 膠着狀態 이다. 優先順位逆轉은 높은 順位의 作業이 낮은 順位의 細麻布語를 가지는 作業을 기다리는 狀況이다. 代表的인 解決法은 細麻布語를 가지는 作業이 最優先順位가 되도록 하는 것이다. 膠着에서는 두 個의 作業이 두 個의 細麻布語를 逆順으로 잠근다. 이것은 大槪大氣熱을 具現할 때 綿密하게 設計하거나 또는 floored semaphores(定해진 狀況에서 細麻布語의 制御權을 높은 順位의 作業에 넘기는)를 追加함으로써 解決된다.

메시지 傳達 [ 編輯 ]

다른 解決策은 作業들이 서로 메시지를 주고 받게 하는 것이다. 이것 또한 똑같은 問題點들을 안고 있다: 作業이 낮은 優先順位의 메시지를 遂行하느라 in-box에 있는 더 높은 順位의 메시지를 無視할 때 優先順位逆轉이 일어난다. 두 個의 作業이 서로 相對方의 應答을 기다릴 때 膠着이 일어난다.

實時間動作은 細麻布어 시스템의 境遇보다는 덜 분명하지만, 메시지 基盤 시스템들은 自體的으로는 固定的이지 않아 一般的으로 細麻布어 시스템들보다는 더 잘 動作한다.

인터럽트 핸들러와 스케줄러 [ 編輯 ]

인터럽트 핸들러는 實行中인 가장 높은 優先의 태스크 조차도 中斷 시킬 수 있으며, 實時間運營體制는 스레드 待機時間을 最少化하도록 設計되어 있기 때문에, 인터럽트 핸들러의 機能은 可能한 最少化되기 마련이다.

메모리 割當 [ 編輯 ]

實時間運營體制의 메모리 割當 은 다른 運營體制에서보다 더 致命的이다.

첫째로, 安定性을 위해서 메모리 漏水 (割當되었지만 使用後返還되지 않은 메모리)는 있을 수 없다. 裝置는 한番의 再부팅度必要없이 無限定動作해야 한다. 이러한 理由로 動的 메모리 割當 은 눈살이 찌푸려진다. 可能할 때에는 반드시, 모든 要求되는 메모리 割當은 컴파일 時間에 靜寂으로 明示된다.

動的 메모리 割當을 避하는 다른 理由는 메모리 斷片化이다. 斷片化된 割當과 작은 메모리 덩이들의 返還으로, 使用可能한 메모리가 여러 섹션으로 나눠져, 充分한 餘裕 메모리가 있음에도 不拘하고 RTOS가 充分히 連續的인 큰 메모리 블록을 割當할 수 없는 狀況이 일어날 수 있다. 둘째로, 割當速度가 重要하다. 一般的인 메모리 割當設計는 適切한 餘裕 메모리 블록을 찾기 爲해 가늠할 수 없는 길이의 連結 리스트를 스캔한다. ^[2] 이는 메모리 割當이 確實한 時間안에 일어나야하는 緣由로 RTOS에서는 容納될 수 없다.

物理的인 디스크는 훨씬 더 길고 豫測할 수 없는 應答時間을 가지기 때문에, 디스크 파일로 交換하는 것은 위에서 論議한 RAM 割當과 같은 理由로 使用되지 않는다.

簡單한 임베디드 시스템 에는 單純한 固定 크기 블록 알고리즘이 낮은 固定費用때문에 相當히 잘 動作한다.

임베디드 시스템의 메모리 使用 [ 編輯 ]

몇몇의 RTOS(임베디드 運營體制)는 XIP (卽席에서 實行)를 支援한다. 커널과 應用 프로그램들이 코드를 RAM 으로 먼저 電送하지 않고 ROM 에서 直接實行된다. 運營體制의 必要한 RAM 크기와 ROM 크기 사이의 交換을 提供한다. [1]

多樣한 RTOS들 [ 編輯 ]

많은 會社들이 리눅스 에 實時間機能을 加味한 버전을 販賣하고 있다. 2004年 10月 8日 몬打비스타 는 리눅스 커널 메일링 리스트 를 통해 리눅스에 實時間性能을 向上하기 위한 實時間 패치 를 公開했다.

같이 보기 [ 編輯 ]

各州 [ 編輯 ]

↑ Tanenbaum, Andrew (2008). 《Modern Operating Systems》. Upper Saddle River, NJ: Pearson/Prentice Hall. 160쪽. ISBN 978-0-13-600663-3 .
↑ CS 241, University of Illinois

[Tanenbaum-1] Tanenbaum, Andrew (2008). 《Modern Operating Systems》. Upper Saddle River, NJ: Pearson/Prentice Hall. 160쪽. ISBN 978-0-13-600663-3 .

[2] CS 241, University of Illinois

[1]

[2]

設計 方式 [ 編輯 ]