신문
-
"러시아군 우크라에 이미 진입…국민들은 피란길"...EU, 긴급 회의 소집
"전쟁불사, 지금까지 이런 대규모 군 대치는 없었다"…신냉전 최전선 된 우크라무섭다.. 진짜 역사 책에서만 보던 거를 볼 거라고 감히 누가 상상했겠나.
당연히 그냥 지나가는 또 하나의 갈등일 줄 알았다.
만약 더 진지하게 이 전쟁이 이뤄진다면 피해는 얼마나.. 발생하고 이득은 누가 볼까
암튼 요 근래 동안 주식, 암호화폐등의 변동성이 클 것은 당연시하고 있어야 겠다.
이 뿐만 아니라 원유, 곡물 등의 가격도 오르는 것을 보면 참.. 영향력이 크다.
족히 이 사태가 끝나길 바란다. -
내달 주총 앞두고 자사주 5000주 매입한 삼성전자 사장…왜?
"이 사장의 이번 자사주 매입은 책임경영 강화와 주주가치 제고 일환으로 해석된다."
오늘 사려고 했는데 회의하다가 잊어버렸다..
내일 장을 보고 결정해야 겠다. -
"특정 분야에 한해 데이터를 모아 AI의 성능을 탁월하게 만들지, 아니면 AI 알고리즘을 고도화해서 어느 데이터를 넣어도 AI가 작동하게 만들지 여부
구글이나 아마존 모델 중심의 후자에 초점을 맞추면서 '인간 같은 AI'
의료·교육·금융 등 특정 분야의 데이터를 모아 기존 일을 효율화하는 데 AI다만 디자인상 굴곡이 많거나, 복잡하게 설계돼 있어 카메라로 다 검사하지 못하는 '사각지대'가 있는 제품이 있을 수 있다."
이걸 보면 영상처리는 공부를 해봐야 될 거 같다.
특정 데이터도 중요하지만 역시나 알고리즘도 그에 비례한다. 이 부분들이 좀 재밌긴 하니까 다 찍먹 해봐야겠다.
DeadLock
운영체제
DeadLock
wait 큐에서 대기중인 모든 프로세스들이 동일한 곳에서 대기중인 다른 프로세스에 의해서만 실행이 가능한 경우.
발생 조건 (4가지 모두 만족하는 경우 DeadLock 발생)
1. Mutual Exclusion
2. Hold and Wait
3. No Preemption
4. Circular Wait
RAG
Resource가 어떤 쓰레드에 할당되었는지, 어떤 Resource를 요청하는지를 보여주는 방향 그래프.
cycle이 존재하지 않는 경우 => DeadLock 없음.
cycledl 존재하는 경우 => DeadLock이 있을 수도, 없을 수도 있음.
대응하는 방식
1. 무시
2. 예방하고 피하기 (Banker's Algorithm)
3. 감지하고 해결하기.
예방
Mutual Exclusion -> 본질적으로 non - sharable해서 이는 원하는 대로 바꿀 수 없음.
Hold and Wait -> 쓰레드가 요청을 날릴 떄 자원을 안 가지고 있게 할 수는 있는데 사용하기가 힘듬
No Preemption -> Preemption을 넣으면 해당 쓰레드가 계속 재시작 되나 봄.
Circular Wait -> 이걸로 감지 가능.
그러나, 기기의 활용도가 낮아지고 시스템의 처리량이 감소할 수 있음.
회피
deadlock이 발생할 수 있다면 쓰레드를 좀 기다리게 하기.
이를 위해서는 얼마나 많은 자원이 할당될 것인지를 알아야 한다.
priori 정보 사용
: 언제나 safe state에 존재하게 해서 DeadLock을 회피한다.
- 각 쓰레드가 필요한 최대치의 자원의 수를 기록한다.
- 쓰레드에 할당된 자원, 할당이 가능한 자원을 구분한다.
RAG의 사용 (자원의 객체가 1개인 경우)
cycle - detection을 이용해 쓰레드의 상태를 판단한다.
싸이클이 없는 경우에만 자원의 할당이 가능하여 DeadLock을 피한다.
Banker's Algorithm (자원의 객체가 여러 개인 경우)
구성 요소
Available : 할당 가능한 자원의 수
Max : 각 쓰레드가 요청하는 최대의 자원의 수
Allocation : 각 쓰레드에게 할당된 자원의 수
Need : 각 쓰레드가 요청할 자원의 수
Safety
Max치의 자원을 할당이 가능한 쓰레드를 찾는다.
그 후 해당 Allocated 되어 있는 자원을 Available로 옮긴다.
이를 계속 반복한다.
Resource - Request
해당 Request를 바로 수행할 수 있는지를 보는 것이다.
현재의 Available이 Request보다 모두 커야 한다.
모두 큰 경우에는 할당을 하고 해당 쓰레드의 Need를 Request에 대해 빼줘야 한다.
이 때도 이 둘을 비교해서 Request가 더 크면 안 된다.
감지
Resource의 객체가 1개인 경우 -> wait - for graph(RAG의 변형)에서 사이클을 찾기.
Resource의 객체가 여러개인 경우 -> banker's algorithm과 같은 것을 사용
Recovery
detection을 언제 할 것인가? 매 요청 마다 or 지정된 시간마다.
이 detection을 위해서도 시간이 사용된다는 것을 알아야 한다.방식
Operator에게 알림, 자동으로 Resource Preemption 또는 쓰레드를 제거하기.
