목차
▲ 개요
▲ 기존 루틴 분석
1.Alarm클래스 분석
2.ThreadSelfTest 분석
3.Semaphore에서 P(),V() 분석
▲ 새로 구현된 코드 분석
1.Alarm::WaitUntil()
2.scheduler
3.synchronization
▲ 테스트 방법 제시
▲ 기존 루틴 분석
1.Alarm클래스 분석
2.ThreadSelfTest 분석
3.Semaphore에서 P(),V() 분석
▲ 새로 구현된 코드 분석
1.Alarm::WaitUntil()
2.scheduler
3.synchronization
▲ 테스트 방법 제시
본문내용
버퍼에 문자열을 넣는 producer 쓰레드 여러개와 버퍼에서 문자열을 빼가는 여러개의 consumer 쓰레드가 서로 뒤엉켜서 실행되지 않도록 동기화를 하게 만들었습니다. 기본이 되는 개념으로 producer라는 객체는 "Hello World"를 3개의 슬롯을 가지고 있는 버퍼에 다 넣을 때까지 끝나지 않습니다. 그리고 consumer라는 객체는 그 슬롯에서 원하는 모든 문자를 다 꺼내기 전에는 종료가 되지 않습니다. 여기서 이 둘의 상호작용을 돕는 도구로서 context-switch를 이용하는데 producer나 consumer나 누군가가 슬롯에 액세스하는 작업을 하다가 context-switch에 의해 다른 쓰레드가 작업권한을 가지게 된다면 버퍼의 값에 오류가 생길수도 있게 때문에 lock을 사용합니다. 여기서 lock는 기존에 있던 것이 아니라 새로 구현한 것입니다.
실행방법은 ./nachos -P 로 하거나 ./nachos -P -q <숫자> 로 실행시키면 됩니다.
--정상 동작 여부를 시험해 볼 수 있는 테스트 케이스 제시:
자료는 "Hello World"이며 버퍼의 크기는 3입니다. 괄호 안의 자료중 앞의 숫자는 consumer 쓰레드의 번호입니다. 그리고 뒤의 글자는 버퍼에서 가져온 값입니다. producer와 consumer의 관계로는 만약 producer쓰레드가 1번이면 그의 자료를 가져오는 consumer쓰레드는 2번이고 3번이 버퍼에 자료를 넣으면 4번만이 3의 자료를 가져올 수 있게 했습니다.
- case 1
실행결과 ./nachos -P -q 30
[o200311308@pluto build.linux]$ ./nachos -P -q 30
(2,H) (2,e) (4,H) (2,l) (4,e) (2,l) (6,H) (4,l) (2,o) (6,e) (4,l) (2, ) (6,l) (4,o) (2,W) (6,l) (4, ) (2,o) (6,o) (4,W) (2,r) (6, ) (4,o) (2,l) (6,W) (4,r) (2,d) (6,o) (4,l) (16,H) (6,r) (4,d) (18,H) (6,l) (16,e) (20,H) (6,d) (18,e) (12,H) (16,l) (20,e) (12,e) (18,l) (8,H) (12,l) (12,l) (8,e) (12,o) (12, ) (8,l) (12,W) (12,o) (8,l) (12,r) (12,l) (8,o) (12,d) (18,l) (8, ) (18,o) (18, ) (8,W) (18,W) (18,o) (8,o) (18,r) (18,l) (8,r) (18,d) (10,H) (8,l) (10,e) (20,l) (8,d) (10,l) (10,l) (16,l) (10,o) (10, ) (10,W) (20,l) (10,o) (10,r) (10,l) (20,o) (10,d) (20, ) (16,o) (20,W) (14,H) (16, ) (20,o) (20,r) (16,W) (14,e) (20,l) (20,d) (14,l) (16,o) (14,l) (16,r) (14,o) (14, ) (16,l) (16,d) (14,W) (14,o) (14,r) (14,l) (14,d) Machine halting!
Ticks: total 16990, idle 0, system 16990, user 0
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 0
Paging: faults 0
Network I/O: packets received 0, sent 0
부연설명
알아보기 쉽게 하기위해 결과 값을 가져와서 특정 쓰레드만 색칠해봤습니다.
- case 2
실행결과 ./nachos -P
[o200311308@pluto build.linux]$ ./nachos -P
(2,H) (2,e) (2,l) (4,H) (4,e) (4,l) (6,H) (6,e) (6,l) (10,H) (10,e) (10,l) (4,l) (4,o) (4, ) (8,H) (8,e) (8,l) (10,l) (10,o) (10, ) (4,W) (4,o) (4,r) (20,H) (20,e) (14,H) (8,l) (8,o) (16,H) (18,H) (18,e) (10,W) (2,l) (2,o) (4,l) (16,e) (16,l) (6,l) (10,o) (10,r) (20,l) (18,l) (18,l) (8, ) (4,d) (12,H) (6,o) (6, ) (8,W) (20,l) (20,o) (18,o) (8,o) (8,r) (20, ) (2, ) (2,W) (18, ) (10,l) (10,d) (2,o) (6,W) (6,o) (8,l) (6,r) (6,l) (14,e) (6,d) (12,e) (12,l) (12,l) (16,l) (16,o) (16, ) (14,l) (14,l) (14,o) (12,o) (12, ) (12,W) (16,W) (16,o) (16,r) (14, ) (14,W) (14,o) (12,o) (12,r) (12,l) (16,l) (16,d) (18,W) (14,r) (14,l) (2,r) (18,o) (18,r) (14,d) (12,d) (2,l) (2,d) (20,W) (20,o) (20,r) (20,l) (20,d) (18,l) (18,d) (8,d) Machine halting!
Ticks: total 54750, idle 0, system 54750, user 0
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 0
Paging: faults 0
Network I/O: packets received 0, sent 0
부연설명
타임퀀텀을 크게 주게되면 버퍼의 수가 적기 때문에 3개의 슬롯을 다 채워버리고 남은 시간 동안 루프를 돌면서 대기하게 됩니다.
--수행 결과를 변경/추가 부분과 관련한 설명:
이 작업을 가능하게 하기위해 Producer, Consumer, Buffer, MyLock 4개의 클래스를 따로 만들었습니다. 테스트를 하면서 타임 퀀텀 값을 계속 늘여나가면 일정하지는 않지만 total tick의 증가 추세가 보입니다.
실행방법은 ./nachos -P 로 하거나 ./nachos -P -q <숫자> 로 실행시키면 됩니다.
--정상 동작 여부를 시험해 볼 수 있는 테스트 케이스 제시:
자료는 "Hello World"이며 버퍼의 크기는 3입니다. 괄호 안의 자료중 앞의 숫자는 consumer 쓰레드의 번호입니다. 그리고 뒤의 글자는 버퍼에서 가져온 값입니다. producer와 consumer의 관계로는 만약 producer쓰레드가 1번이면 그의 자료를 가져오는 consumer쓰레드는 2번이고 3번이 버퍼에 자료를 넣으면 4번만이 3의 자료를 가져올 수 있게 했습니다.
- case 1
실행결과 ./nachos -P -q 30
[o200311308@pluto build.linux]$ ./nachos -P -q 30
(2,H) (2,e) (4,H) (2,l) (4,e) (2,l) (6,H) (4,l) (2,o) (6,e) (4,l) (2, ) (6,l) (4,o) (2,W) (6,l) (4, ) (2,o) (6,o) (4,W) (2,r) (6, ) (4,o) (2,l) (6,W) (4,r) (2,d) (6,o) (4,l) (16,H) (6,r) (4,d) (18,H) (6,l) (16,e) (20,H) (6,d) (18,e) (12,H) (16,l) (20,e) (12,e) (18,l) (8,H) (12,l) (12,l) (8,e) (12,o) (12, ) (8,l) (12,W) (12,o) (8,l) (12,r) (12,l) (8,o) (12,d) (18,l) (8, ) (18,o) (18, ) (8,W) (18,W) (18,o) (8,o) (18,r) (18,l) (8,r) (18,d) (10,H) (8,l) (10,e) (20,l) (8,d) (10,l) (10,l) (16,l) (10,o) (10, ) (10,W) (20,l) (10,o) (10,r) (10,l) (20,o) (10,d) (20, ) (16,o) (20,W) (14,H) (16, ) (20,o) (20,r) (16,W) (14,e) (20,l) (20,d) (14,l) (16,o) (14,l) (16,r) (14,o) (14, ) (16,l) (16,d) (14,W) (14,o) (14,r) (14,l) (14,d) Machine halting!
Ticks: total 16990, idle 0, system 16990, user 0
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 0
Paging: faults 0
Network I/O: packets received 0, sent 0
부연설명
알아보기 쉽게 하기위해 결과 값을 가져와서 특정 쓰레드만 색칠해봤습니다.
- case 2
실행결과 ./nachos -P
[o200311308@pluto build.linux]$ ./nachos -P
(2,H) (2,e) (2,l) (4,H) (4,e) (4,l) (6,H) (6,e) (6,l) (10,H) (10,e) (10,l) (4,l) (4,o) (4, ) (8,H) (8,e) (8,l) (10,l) (10,o) (10, ) (4,W) (4,o) (4,r) (20,H) (20,e) (14,H) (8,l) (8,o) (16,H) (18,H) (18,e) (10,W) (2,l) (2,o) (4,l) (16,e) (16,l) (6,l) (10,o) (10,r) (20,l) (18,l) (18,l) (8, ) (4,d) (12,H) (6,o) (6, ) (8,W) (20,l) (20,o) (18,o) (8,o) (8,r) (20, ) (2, ) (2,W) (18, ) (10,l) (10,d) (2,o) (6,W) (6,o) (8,l) (6,r) (6,l) (14,e) (6,d) (12,e) (12,l) (12,l) (16,l) (16,o) (16, ) (14,l) (14,l) (14,o) (12,o) (12, ) (12,W) (16,W) (16,o) (16,r) (14, ) (14,W) (14,o) (12,o) (12,r) (12,l) (16,l) (16,d) (18,W) (14,r) (14,l) (2,r) (18,o) (18,r) (14,d) (12,d) (2,l) (2,d) (20,W) (20,o) (20,r) (20,l) (20,d) (18,l) (18,d) (8,d) Machine halting!
Ticks: total 54750, idle 0, system 54750, user 0
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 0
Paging: faults 0
Network I/O: packets received 0, sent 0
부연설명
타임퀀텀을 크게 주게되면 버퍼의 수가 적기 때문에 3개의 슬롯을 다 채워버리고 남은 시간 동안 루프를 돌면서 대기하게 됩니다.
--수행 결과를 변경/추가 부분과 관련한 설명:
이 작업을 가능하게 하기위해 Producer, Consumer, Buffer, MyLock 4개의 클래스를 따로 만들었습니다. 테스트를 하면서 타임 퀀텀 값을 계속 늘여나가면 일정하지는 않지만 total tick의 증가 추세가 보입니다.