일괄 처리 시스템(batch system)등의 경우 단위 시간당 처리율(Throughput)이 핵심지표가 된다.
프로세스의 긴급성(Urgency)
hard-realtime : 지정된 응답시간 내에 반응에 실패할 경우 심각한 피해가 발생하는 시스템
soft-realtime : 지정된 응답시간 내에 반응에 실패할 경우 성능저하가 발생할뿐 동작엔 문제가 없는 시스템
non-realtime : 실시간 시스템이 아닌 경우
프로세스의 우선순위(Priority)
프로세스의 실행시간(Service Time)
3. 스케줄링의 단계
Short-Term 스케줄링
Ready Queue에서 대기중인 프로세스중 어느 프로세스에게 프로세서(CPU)를 할당할지 결정
일반적으로 말하는 스케줄링은 단기 스케줄러에 의한 스케줄링을 의미함
가장 자주 발생하는 스케줄링이기 때문에 성능에 미치는 영향도 매우큼 => 속도가 매우 빨라야한다.
Mid-Term 스케줄링
너무 많은 프로세스에게 메모리를 할당하여 시스템 성능이 저하될 경우 메모리에 적재된 프로세스의 수를 유동적으로 조절하
메모리에 적재될 프로세스중 일부를 선택하여 컨텍스트를 디스크의 스왑 영역에 저장해두고 메모리를 해제한다. 이를 스왑 아웃(Swap Out)이라 한다.
Long-Term 스케줄링
메모리에 동시 적재 가능한 프로세스의 수(multi-programming degree) 조절 => Ready Queue 에 들어갈 프로세스의 수 조절
현대의 시분할 시스템이나 실시간/대화형 시스템의 경우 장기 스케줄러를 두지 않거나 최소화시킴
시분할 시스템의 경우 모든 프로세스에 공평하게 정해진 시간동안 자원을 분배하기 위해, 실시간/대화형 시스템의 경우 요청을 받았을 때 정해진 시간 내에 응답하기 위해 바로 메모리를 할당하고 Ready Queue에 넣어야하기 때문에 Long-Term 스케줄링의 의미가 없기 때문
일괄 처리 시스템(batch system)에 적합하다.
4. 스케줄링 정책
비선점 스케줄링(Non-preemptive Scheduling)
한번 자원을 할당받고나면 실행이 완료되고 이를 반납하기 전까지 사용할 수 있음
보다 우선순위가 높은 프로세스가 도착하더라도 자신의 작업은 끝까지 수행할 수 있음
한 작업이 모두 수행되기 전까지 다른 작업에 대해 응답할 수 없기에 평균 응답시간이 길어짐
우선순위가 높은 작업이 먼저 실행되기 시작한 우선순위가 낮은 작업에 밀리는 경우가 자주 발생
하나의 프로세스가 실행을 마칠 때 까지 Context Switching이 발생하지 않아 오버헤드가 적음
선점 스케줄링(Preemptive Scheduling)
자원을 할당받은 후 실행이 아직 완료되지 않았어도 보다 우선순위가 높은 프로세스가 도착하거나 자신의 사용시간이 만료되면 자원을 반납해야함
선점에 의한 Context Switching 이 자주 발생 => 오버헤드가 큼
시분할 시스템이나 실시간/대화형 시스템에는 이 방식이 적합
우선순위(Priority)의 결정
정적 우선순위(Static Priority)
프로세스 생성시 변하지 않는 우선순위를 지정
구현이 쉽고 overhead가 적음
상황 변화에 따른 유연한 대처 불가
동적 우선순위(Dynamic Priority)
프로세스의 상태 변화에 따라 Priority 변경
구현이 복잡하고 Priority 계산을 위한 overhead가 발생
상황 변화에 따른 유연한 대처 가능
5. 스케줄링 알고리즘
① 비선점형 스케줄링 알고리즘
FCFS(First Come First Served)
대기열에 먼저 들어온 프로세스를 우선적으로 실행하는 알고리즘
장점
구현이 매우 간단하며 오버헤드 또한 거의 없음
작업이 종료될 때를 제외하면 Context Switching이 발생하지 않아 CPU 사용률이 매우 높다
도착한 작업은 자신의 순서가 오면 반드시 실행되기에 starvation(기아) 이 발생하지 않는다.
단점
평균 응답시간이 매우 길다
하나의 오래걸리는 작업으로 인해 다른 작업들의 대기시간이 길어지는 문제
SJF(Shortest Job First)
실행시간(Burst Time)이 가장 적은 프로세스가 우선적으로 실행되는 알고리즘
장점
평균 대기시간 최소화
시스템 내 프로세스의 수를 최소화(실행시간이 짧은 작업들이 빠르게 종료되기 때문)
단점
프로세스의 실행시간을 정확히 예측하는 것이 현실적으로 어려움
실행시간이 긴 프로세스가 계속해서 우선순위에서 밀리는 starvation(기아)이 발생
HRRN(Highest Response Ratio Next)
Response Ratio 공식에 따라 계산된 우선순위가 높은 프로세스를 우선적으로 실행하는 알고리즘
Response Ratio = (Service Time + Waiting Time) / Service Time
서비스 시간이 짧을수록, 대기시간이 길수록 우선순위가 높아지는 방식
대기시간의 증가에 따라 우선순위가 높아져 starvation이 발생하지 않도록 하는 에이징(aging) 기법을 사용
② 선점형 스케줄링 알고리즘
RR(Round Robin)
FCFS의 선점형 버전
기본적으로는 대기열에 가장 먼저 도착한 프로세스를 먼저 처리
대신 자원의 사용 시간에 제한을 두어 시간이 만료되면 자원을 반납하고 대기열의 맨 뒤로 간다
장점
특정 프로세스에 의한 자원 독점의 방지
평균 응답시간이 길어지는 문제 해결
단점
잦은 Context Switch로 인한 오버헤드가 큼
시분할 시스템이나 실시간/대화형 시스템에 적합
SRT(Shortest Remaining Time)
SJF의 선점형 버전
남은 실행시간이 가장 적은 프로세스를 먼저 처리
남은 실행시간이 더 적은 프로세스가 대기열에 들어오면 그 프로세스에 의해 자원이 선점당함
장점
SJF의 장점(대기시간의 최소화, 시스템 내 프로세스 수의 최소화)을 극대화
단점
SJF와 마찬가지로 실행시간(Burst Time)의 측정이 어려움
남은 실행시간(Remaining Time)을 지속적으로 추적해야함
MLQ(Multi Level Queue)
프로세스들을 그룹화하여 그룹마다 독자적인 큐(대기열)를 사용하는 스케줄링 기법
프로세스는 작업의 특성(작업의 중요도, 빠른 응답시간이 요구되는지 등)에 따라 분류
각 큐는 그 특성에 맞는 독자적인 스케줄링 기법을 적용
한번 배정된 큐에서는 이동할 수 없음
큐 사이에는 우선순위 기반의 스케줄링 사용
장점
작업의 특성에 따라 적합한 스케줄링 기법을 독립적으로 적용 가능
단점
여러개의 큐를 관리해야하는 만큼 스케줄링의 오버헤드가 보다 큼
우선순위가 낮은 큐의 starvation이 발생할 수 있음
처음에 프로세스를 적절한 큐에 배정하지 못하면 이동이 불가능하기에 프로세스에 대한 사전정보가 필요
MFQ(Multi Level Feedback Queue)
프로세스가 처음 배정된 큐에서 다른 큐로 이동 가능해진 MLQ 방식
Feedback 을 통해 우선순위를 조정
프로세스에 대한 사전정보를 알지 못해도 HRN과 비슷한 효과를 볼 수 있음
장점
MLQ가 그러했듯이 각 큐마다 별도의 스케줄링 정책을 사용하는 것으로 프로세스의 특성에 적합한 스케줄링 방식 적용이 가능
입출력 위주(I/O Bounded)의 프로세스를 상위 큐로 이동 => I/O 위주의 프로세스는 CPU 사용시간이 짧기 때문(적은 service time)
대기시간이 길어진 프로세스를 상위 큐로 이동(Aging) => starvation 의 방지
어떤 사람의 공개키를 사용하여 암호화된 데이터는 그 사람의 개인키를 사용해야 복호화할 수 있음
어떤 사람의 개인키를 사용하여 암호화된 데이터는 그 사람의 공개키를 사용해야 복호화할 수 있음
키를 교환할 필요 없이 상대의 공개키를 사용하여 암호화한 뒤 데이터를 전송하면 보안이 보장됨
암호화/복호화에 걸리는 시간이 대칭키 암호화방식에 비해 훨씬 길다
DSA, RSA, ECC 등의 알고리즘이 있다.
3. 인증(Authentication) - 전자서명
통신중인 상대가 정말 본인이 맞는지 확인이 필요
공개키 암호화를 응용하여 본인을 인증
상대에게 랜덤 데이터를 보내고 상대는 이를 자신의 개인키로 암호화하여 전송
상대의 공개키로 이 데이터가 정상적으로 복호화된다면 상대가 본인임을 인증할 수 있음
4. 인증기관(Certificate Authority)
공개키 암호화를 사용한 인증방식에도 문제가 있음
만약 상대가 보낸 암호화된 랜덤데이터와 공개키 모두 전혀 다른사람의 것이어도 알아챌 수 없음
이를 보장해줄 신뢰성있는 제 3자가 필요 => 인증기관의 필요성
인증기관(CA)은 자신의 비밀키로 암호화된 인증서를 제공하고 사용자는 이를 CA의 공개키로 복호화, 인증기관이 발행한 인증서임을 확인함과 동시에 인증서를 통해 식별하고자 하는 상대방의 공개키와 정보를 얻게된다. 이를 통해 전자서명을 통한 상대방의 본인 여부를 확인할 수 있다.
상태표시줄에 표시된 날짜/시간 부분을 클릭하면 데이터를 조회할 날짜를 선택하기 위한 달력 위젯이 표시되도록 하기 위해 먼저 TimeLabel의 mouseReleaseEvent 를 오버라이드하여 clicked 시그널을 구현해준다.
3. MainWindow 수정
# 시간 레이블 추가
time_label = TimeLabel()
time_label.clicked.connect(lambda: actions.date_query(self, self.central_widget.get_selected_tab()))
status_bar.addPermanentWidget(time_label)
MainWindow의 time_label을 상태표시줄에 추가하는 부분에서 time_label의 clicked 시그널에 date_query를 호출하는 람다함수를 연결해준다. 이 때, central_widget의 get_selected_tab 을 호출하여 현재 선택된 탭 정보를 받아와 매개변수로 넘겨준다.
4. CentralWidget 수정
# 중앙 위젯
class CentralWidget(QWidget):
def __init__(self, parent):
super().__init__(parent)
self.doc_tab = DocTab()
self.doc_tab.setParent(self)
self.init_ui()
def init_ui(self):
self.setStyleSheet("background-color: #FFFFFF")
# 그리드 레이아웃
grid = QGridLayout()
# 탭 위젯 추가
grid.addWidget(self.doc_tab, 0, 0)
# 중앙 위젯에 그리드 레이아웃 적용
self.setLayout(grid)
def get_selected_tab(self):
cur = self.doc_tab.currentWidget()
return 0 if cur == self.doc_tab.tab1 else 1 if self.doc_tab.tab2 else 2
CentralWidget에 선택된 탭이 몇번 탭인지 반환하는 get_selected_tab 메소드를 구현한다
tab1이라면 0, tab2라면 1, tab3라면 2를 반환한다.
5. date_query 함수 작성
# 날짜로 데이터 조회
def date_query(parent, tab):
date_select = DateSelect(parent)
date_select.show_modal()
if not date_select.canceled:
if tab == 0:
today = date_select.calendar.selectedDate().toString('yyyy-MM-dd')
result = DayCalQueryResult(parent, get_daycal_owner_values(today), get_daycal_other_values(today), get_daycal_result(today), today)
result.show()
호출시에 매개변수로 전달받은 parent 를 부모 위젯으로 하여 DataSelect 다이얼로그를 생성, modal하게 표시한다 => DataSelect 는 달력 위젯을 사용하여 유저가 선택한 날짜를 가져오기 위한 위젯이다.
DataSelect 다이얼로그가 정상적으로 제출되었을 경우 받아온 날짜를 기준으로 DayCalOwnerValues, DayCalOtherValues, DayCalResult 정보를 DB에서 읽어온다.
읽어온 정보를 기반으로 DayCalQueryResult 위젯을 생성하여 표시한다. => DayCalQueryResult 는 조회된 데이터를 테이블로 나타내주기 위한 위젯이다.
