@ 위 이유의 결과로 IBM은 I/O channel(I/O device controlor)를 개발하게 되었습니다
// 이를 통해, CPU는 I/O Operation의 시작과 끝에만 관심을 둘 수 있게 되었습니다.
> 매커니즘 : CPU >> I/O command >> I/O channel >> (결과값 생성) >> Interupt 매커니즘 >> CPU 전달
> 단, 위의 과정은 asyncronisys 입니다. 이것이 바로 문제를 발생시킵니다.
? Problem. I/O operation의 모든 종류가 CPU와 I/O operation을 분리시킬 수 있을까요?
// 답은 No 입니다.
> 예를 들어 디스크에서 정보를 읽어올 때 디스크 정보를 읽어오는 read operaration(이하 op)
> 이 이후의 op의 경우 read op 수행 완료 전에는 수행을 시작할 수 없습니다.
> 이 때문에 'interrupt' 할 수 없게 됩니다. (Overlap 불가능)
@ 그렇다면 asyncronous는 무엇인가요? (반대는 syncronous 입니다)
// 비동기적(asyncronous : async) I/O operation(이하 op)
> 앞의 op의 종료여부에 관계없이, 뒤의 op가 수행될 수 있는 것 (overlap 가능)
> 대부분의 input op (전부는 아니다)
// 동기적(syncronous : sync) I/O op
> 앞의 op이 종료되어야만, 다음 op이 수행될 수 있는 것
> 대부분의 output op (전부는 아니다)
@ 당시 기술로는 async I/O에 대해 CPU와 I/O op을 Overlap 시켰습니다.
// 단, sync에 대해서는 그렇지 못했습니다.
> 하지만 이 sync op는 많은 프로그램에 있어서 적지 않은 파트를 차지합니다.
@ 당시는 하나의 job에 대해서만 CPU가 연산을 진행했지만, 위의 문제를 해결하기 위해서는 여러 job을 수행할 수 있어야 했습니다. (다른 sync가 발생할 때, 아예 다른 job을 수행
// 이러한 이유에서, Multi programed batch monitor가 등장하게 됩니다.
