코로나19로 인해 유명 박람회들이 죄다 연기, 혹은 취소되는 상황에 올해가 끝나가는 이제야 참가할만한 기술 박람회를 맞이할 수 있게 되었다. 한국전자전은 내년으로 연기되었지만, 반도체대전은 올해 개최된다는 것을 보고 거리는 다소 있지만 참관을 결정하게 되었다. 이와 함께 마침 일정이 겹치게 되어 2020 국제인공지능대전도 같이 둘러보기로 했다.
다만 경제 상황이 악화되었던게 문제인지, 작년에 비해서 규모나 분위기가 많이 위축되었다는 점이 많이 느껴져 아쉬움이 남았다. 보통은 전시 마지막날 참관을 하곤 했는데, 올해는 어쩌다 보니 개최 첫날 오전 타임이어서 그럴지도 모른다는 생각이 들었지만, 사회적 거리두기와 맞물려 박람회에 방문한 사람 수가 줄었다는 느낌은 어쩔 수 없는 것 같았다.
2020 국제 인공지능대전
국제인공지능대전에서는 AI와 관련된 HW 및 SW 등 다양한 서비스를 제공하는 기업들을 만나볼 수 있었다. 크게 AI 학습용 GPU서버(Nvidia와 협력 관계를 맺는 회사들이 종종 보였다.), 데이터 학습 및 가공, 그리고 AI모델을 서비스로 제공하는 회사로 크게 분류할 수 있었을 것 같다.
특이했던 점은 기업 대부분이 소규모 혹은 스타트업에 가까웠다는 점이다. 그만큼 AI의 힘을 빌어 핀포인트로 제공 가능한 서비스가 많아졌고, 그와 더불어 AI로 창출 가능한 사업 가능성이 다변화되었음을 의미하는 것 같았다.
기억에 남는 기업이 두 곳 있었는데, 하나는 인피닉이라는 기업이었다. 기존에는 임베디드 및 QA서비스 제공을 하다가, 최근 데이터 관리 사업을 시작한 것으로 보인다. 데이터 수집부터 QA까지 전반적인 전반적인 구축 시스템을 제공하며, 박람회에서는 그 결과물로 영상처리를 기반으로 상품 목록을 자동 인식하는 무인 점포 시스템을 시연 중이었다.
또하나의 기업은 코어닷투데이라는 기업이었다. 이곳의 컨셉은 데이터 스토리텔링이라는 개념이었는데, 내가 어떠한 데이터를 분석한 방식을 Jupyter Notebook을 이용해 업로드하여 사람들에게 공유하는 사이트였다. 어쩌면 Kaggle과 유사한 형태인데, 차이점이라면 Kaggle은 기업이 제시한 내용을 해결하는 곳이라면, 이곳은 이용자들이 자신의 주제로 분석하는 과정을 업로드하는 곳이었다. 자기 이론에 맞게 데이터를 분석할 수 있기 때문에 정보의 자유도가 더 높아질 수 있을 것 같고, 좀 더 사용자 중심적일 수 있다는 장점이 돋보이는 서비스라고 생각했다.
2020 반도체대전
SEDEX에서 가장 기억에 남았던 기업은 파스텍이라는 기업으로, 모터 및 컨트롤러 전문 개발 업체였다. 반도체 장비는 극한의 정밀도를 필요로 하는 만큼 로봇에 사용되는 모터 등의 정밀한 제어가 필수적이다. 모터 토크 유지, 3축 등 다양한 방향으로의 정밀 제어를 시연하는 기업이었다.
반도체대전 역시 작년에 비해 아쉬움이 좀 있었는데, 장비나 기술 시연의 규모가 상당히 줄었다는 느낌이 들었다. 그나마 하이닉스/삼성이 자리했고, 램리서치의 경우 간단한 기업 소개 정도만 남아 있는 모습이었다. 거의 기업 시연보다는 해당 박람회에서 기업 간 미팅을 위한 자리를 마련한 곳이 대부분이었던 것 같다.
race condition : 초기값이 5일 때, 동시에 접근 시 Producer는 5 > 6, Consumer는 5 > 4로 Counter 값을 바꾸므로 결과적으로 카운터값이 6>4로 변경될 가능성 존재
fork()의 race condition
fork 실행 시 반환값은 PID
두 프로세스가 동시에 fork 호출 시 같은 PID를 갖는 두 프로세스가 생성될 수 있음
/* Producer Process */while (true) {
/* produce an item in next produced */while (counter == BUFFER_SIZE)
; /* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
/* Consumer Process */while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}
Critical-Section Problem
다수의 프로세스/스레드 생성 시 한 번에 하나의 작업만 실행될 수 있는 구간
공용 데이터 접근시의 충돌 방지
do
{
/* Ask Permission to enter critical section *//* Critical Section *//* Exit Critical Section */
...
}while(...);
Critical Section 문제의 해결 조건
Mutual Exclusion : 프로세스 P가 Critical Section에 접근 시 다른 프로세스는 해당 구간을 실행하면 안됨(Critical Section의 정의)
Progress : Critical Section에 실행 중인 프로세스가 없을 경우, 이 구간에 진입하고자 하는 프로세스를 지연 없이 진입시켜야 함
Bounded Waiting : 프로세스 A가 Critical Section에 있을 때, 새 프로세스가 진입하고자 할 경우 A가 끝나는 것을 대기해야 하나, 무한정 대기해서는 안됨 (Critical Section 진입 시 우선순위의 조정 필요)
OS의 Critical-Section Handling : Non-Preemptive
인터럽트 없이 커널 설계
구현이 쉽고, 오류를 신경쓸 필요성이 낮아짐
공유 데이터 접근 시 우선한 작업이 처리되어야 나머지 처리가 가능하므로 시스템 반응성, 성능이 떨어지게 됨
busy wait : Critical Section에 접근하지 못한 나머지 변수들은 while loop를 돌면서 대기
spin lock : 무한루프를 돌면서 대기하는 형태(busy wait)
Semaphores
Mutex Lock의 경우 한 번에 하나의 프로세스만 Critical Section 진입
Semaphore의 경우 정수 변수 S 값의 설정에 따라 진입 가능한 프로세스 수 설정 가능
wait(S) : 대기 중인 프로세스 조정
signal(S) : 실행이 완료된 프로세스 release
자원 관리에 주로 사용
Busy wait이 없는 Semaphore
프로세스 sleep(), wakeup() 확인
wait : 프로세스 실행이 불가능한 경우 프로세스를 sleep queue에 추가 후 sleep
signal : 프로세스가 추가 실행이 불가능하면서 waiting중인 프로세스 존재 시 해당 프로세스 wakeup
프로세스 리스트 접근 시 mutex section 구현 필요
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
//add this process to S->list;
block();
}
}
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
//remove a process P from S->list;
wakeup(P);
}
}
Monitor
mutex/semaphor의 고레벨 구현
monitor 내에 선언한 함수는 컴파일 단계에서 wait-signal이 구현됨
condition variable
변수에 여러 프로세스가 동시 접근 시 signal - wait 구현
Liveness
Progress, Bounded Waiting으로 보장
프로세스가 일정 시간 내에 실행되는 것을 보장
보장되지 않을 경우 알 수 없는 이유로 시스템이 멈추는 등의 문제 발생
Deadlock
둘 이상의 프로세스가 서로의 자원을 필요로 하는 상황
서로의 wait을 위해 서로의 자원을 필요로 하는 상황
P0의 Q wait을 위해서는 P1이 대기하는 Q가 필요
P1의 S wait을 위해서는 P0이 대기하는 S가 필요
Starvation
프로세스가 공유 자원(Critical Section, Semaphore, ...)을 무한히 대기하는 현상
