하루일지 - 22.02.20

LONGNEW·2022년 2월 20일

2022.02.20 Bounded - Buffer CATL Dining - Philosophers LG엔솔 Semaphore mutex read_count readers - writers rw_mutex 게임주 대기업 수익 실적 유급휴가 착오송금 확진

일지

목록 보기

16/34

신문

"중국이 알면 아마 깜짝 놀랄걸"…LG엔솔은 있고, CATL은 없는 것

"중국을 제외하면 LG에너지솔루션이 36.5%, CATL은 12.9%로 점유율 순위가 뒤바뀐다.
최근 중국 전기차 업체들이 CATL 의존도를 낮추려는 움직임"
우선 중국 시장이 차지하는 비율이 매우 크다. 그리고 현재 CATL이 조금씩 밀려나고 있다. OK
LG엔솔은 그래도 오를 수 있을까? 아니 왜 IPO되는 시점에선 이런 뉴스가 안 나오고 지금 나옴?
왜 그떈 이렇게 분석이 안 되었을까?
다 털고 뭐 던지려는 건가 잘 모르겠다.
사업장 한곳서 무려 40명 무더기 확진…기업들 "회사 오지마라"

"백신휴가를 비롯해 코로나19 확진 시 재택근무, 유급휴가 등은 정부의 [권고사항]이기 때문
회사로부터 유급휴가를 받지 못했다면 근로자가 직접 정부에 생활지원비를 신청할 수 있다"
음.. 대기업은 유급휴가를 주고, 그 외의 경우에는 격리중인 센터에서도 근무를 요구하기도 한다. 걍 무섭다.. 예전에는 그냥 중소와 대기업 차이가 대우의 차이라고 생각했는데 이런 가까운 일? 와 닿는 일이 눈에 보이니 더 편견이 생기는 것 같다.
돈이 돈을 가져오는 것이 이런 것인가 싶기도 하고, 재택 근무가 출근을 하는 것보다 생산성이 없는 것인지 왜 출근을 요구하는 것일까..
이걸 위해 프로그램 계약하고 막 했을텐데 그 돈 왜 쓴건가 그럼.
"아차 축의금 이 계좌가 아니었네" 착오송금 30~40대가 가장 많다

"5만원 이상 1000만원 이하 착오송금은 자진반환이 거절된 건에 한해 예금보험공사(이하 '예보')가 대신 받아주고
먼저 금융회사를 통해 자진반환을 요청해야 하며,
미반환된 경우에만 예보에 착오송금 반환지원 신청
* 보이스피싱 피해 착오송금 반환지원 대상 제외"
이건 잘 알아둬야 겠다. 무슨 일이 발생할 지 모르니까 말이다.
그래도 개인적으로 송금을 하기 전에는 옳은 계좌인지 마지막에 체크하도록 하니까 이를 잘 확인하자.
어닝쇼크에 행렬에 나락으로 간 게임주…증권가도 혹평

게임으로 얻을 수 있는 수익이 어떤 것이 있을까?
현금 매출 (게임 아이템, 게임 구독료)
광고 계약
스포츠 리그 흥행
PC방 라이센스 계약
..
기존의 사업에선 제품을 제작, 판매의 과정이 주를 이루는데 게임에선 아이템을 제작, 판매하는 과정이 일어나야 한다. 근데 현실에선 꼭 필요한 물품에 비해 게임은 있어도 그만 없어도 그만이기 떄문에 이외의 사업 아이템이 필요하다.
NFT등 코인에 발을 들이는 것은 좋다고 생각한다. 비트코인 네트워크를 이뤄주는 것만으로도 리워드가 있는데 각자가 게임의 네트워크를 이루게 된다면 이에 합당한 보상이 생기는 것처럼 말이다.
물론 다른 개념이겠지만.

본인도 요즘 게임을 잘 안 한다. 축구를 모여서 하기 힘드니 피파를 한번씩 하거나, 롤을 하지만 이 게임들이 언제 발매 되었는지 생각하면 변화가 없다.
어느 일본의 개발자의 말에 따르면 "무과금 유저가 많이 존재하고 이들을 이기고 싶어하는 과금 유저가 있는 게임이 밸런스가 좋다 했다"
현재의 게임시장은 올드 게임은 모르겠지만 롤이 너무 꽊 잡고 있지 않나 싶다.
추가적인 매출이 어디서 나올 수 있을까? 차라리 게임회사지만 다른 벤처를 지원하는 방식으로 발을 넓히는 것도 좋지 않나?.. 잘 모르겠다..

프로세스 동기화 문제

운영체제

Bounded - Buffer

n개의 버퍼가 존재할 떄 (각 버퍼는 1개의 아이템을 저장)
생산자는 버퍼에 아이탬을 넣고, 소비자는 이 아이템을 사용한다.

구현

mutex : binary semaphore
=> 버퍼에 접근하는 경우 상호배제를 만족시키기 위해

empty, full : counting semaphore
=> 아이템을 가지고 있는 버퍼의 개수를 나타내기 위함.

Readers - Writers

writer가 없는 경우 무수히 많은 reader가 접근을 해도 아무 에러가 발생하지 않는다.
그러나, writer가 존재한다면 그 때부터는 에러가 터져 나온다.

문제 상황

writer가 ready큐에 있는 경우 원래 reader는 안 기다리고 그냥 접근을 해도 되는데 얘 하나 땜에 대기를 타야 한다.

writer가 무수히 많은데 대기 하고 있는 reader가 하나라면? writer가 다 쓸 때까지 기다려야 함
=> starvation이 발생할 수 있음.

구현

rw_mutex : 임계영역에서 reader, writer에 대한 상호배제를 위해

mutex : reader들이 read하기 위해 가는데 이를 counting하기 위함. count가 임계영역이 되기 때문에 존재.

read_count : 현재 reade해야 하는 공간에 접근한 reader의 개수

상황 설명
1. writer가 임계영역에 존재. 1개의 reader는 rw_mutex에 대한 wait을 , 나머지 reader는 mutex에 대한 wait을 수행 중.
2. writer가 signal을 던질 경우.
현재 rw_mutex를 요구하는 reader, writer들을 모두 ready로 던져서 스케줄러가 고르게 됨.

Locks
위의 mutex가 일반화된 방식으로 read, write Lock을 요구하새 해결하는 방식
read의 경우 여러 프로세스가 요구할 수 있지만 write는 1개의 프로세스만 얻게 됨.

Dining - Philosophers

5명의 철학자가 있을 떄 "생각", "식사"의 행동을 반복적으로 하고, 5개의 젓가락(한 쪽)을 가지고 있다. 젓가락을 2개를 들고 식사를 하고는 내려놓지 않는 경우가 생겼다고 한다.

여러 공유 자원을 여러 명에게 할당해야 하는 문제로 위의 mutex들로 상호배제는 만족시킬 수 있지만 이는 deadlock, starvation을 해결하지는 못한다.

Semaphore
젓가락을 얻기 전에 wait()으로 권한을 얻고 signal()로 권한을 다른 사람에게 준다.
=> mutex는 만족한다. 그러나 이는 deadlock 현상이 발생할 수 있다. (모든 철학자가 동시에 젓가락을 집어 든다면 오른쪽 젓가락은...?)

가능한 해결책
1. 인원을 제한한다.
2. 젓가락을 2개를 들 수 있을 때만 드낟.
3. 홀수번은 왼 -> 오 순서로, 짝수번은 오 -> 왼 순서로 젓가락을 든다.
=> 그래도 starvation을 발생시킬 수 있다.
deadlock을 완전히 예방하는 것은 어렵고 비싸다. 그래서 피하거나 걍 냅둔다고 한다.(나중에 수정하게)

Monitor

철학자가 젓가락을 2개를 들 수 있을 때만 든다.

3개의 상태를 지정한다. "생각중", "배고픔", "식사중"

"식사중"이기 위해선 양 옆의 인원이 "식사중"이 아니어야 한다.

condition variable이 필요. 철학자의 상태를 wait(), notify()하는 용도

코드
void pickUp(int i){
	state[i] = HUNGRY;
    test(i);
    if (state[i] != EATING)
    	self[i].wait();
}
putDown의 경우에도 test를 부르게 되는데.
본인의 상태를 THINKING로 변경했기 때문에 자기 양옆의 사람들이 밥을 먹으려고 하는지 체킹을 하는 것이다.
그래서 양 옆의 사람들이 시그널을 던져서 EATING 상태로 가게 된다.
void putDown(int i){
	state[i] = THINKING;
    test((i + 4) % 5);
    test((i + 1) % 5);
}
void test(int i){
	if ((state[(i + 4) % 5] != EATING) && (state[(i + 1) % 5] != EATING) &&
    	(state[i] == HUNGRY)){
    	state[i] = EATING;
        self[i].signal();
    }
}