Programmer's Digest

*목적  Race Condition방지, data corruption 방지 *Race condition  특정 접근 순서에 따라서 실행결과가 달라지는 경우 *silient corruption  data corruption을 운이좋게 피해간 경우 *Non-preemptive kernel  no race condition. 평균 대기시간 증가 *Critical Section  process들이 공유변수들을 수정할수 있는 코드의 영역 *Critical Section Problem  critical section에는 오직 한 process만 실행되도록 하는 문제 Requirement :  1) mutual exclusion : critical section에는 오직 한 process만이 실행될수 있다. 2) progress : 어떤 process가 임계영역에 들어가려 할때, 무기한 연기가 되어서는 안된다. 3) Bounded Waiting : 어떤 process가 임계영역에 들어가기 위해 대기하는 시간은 유한해야한다. 구현방법: Static Alternation  progress requirement를 만족하지 않음. 한 프로세스가 실행되고나서 다른 process가 실행되기 전까지는 무기한 연기됨. Peterson’s algorithm  progress, Bounded waiting 모두 만족 Special H/W instruction  atomic operation을 코드로 구현하는 것이 아니라, 하나의 instruction으로 구현. Mutex Locks   critical section 문제를 해결하기 위한 SW tool 문제점 : busy waiting이 발생함 bush waiting이란 instruction을 수행하면서 기다림(CPU cycle 낭비) 해결책 :  1) process를 semaphore의 waiting queue에 넣고 wait state로 전환 2) CPU schedular가 다른 process를 schedule 3) 다른 process가

모든 Proceess가 다른 process에 의해 야기될수 있는 event를 기다리고 있을때 발생 *필수조건 1) Mutual Exclusion : 최소 하나의 자원이 비공유 모드로 지원되어야 함 2) hold and wait : process는 최소하나의 자원을 점유한 상태로, 다른 process에 의해 점유된 자원을 얻기 위해 대기해야함 3) No preemption : 자원들은 선점이 될 수 없고, 자발적으로만 방출될수 있다. 4) circular wait : waiting process들이 순환적 대기를 해야한다. * Solution 1) system이 deadlock state에 들어가지 않도록 하는 protocol이 사용(deadlock prevention, deadlock avoidance) 2) system이 deadlock에 들어가도록 허용하되, detect해서 recover하도록 하는 방법 3) 어차피 자주 발생하지 않으므로 무시하는 방법(most popular) deadlock prevention,avoidance 방법은 비용이 너무 크므로 발생하면 재부팅 *Deadlock Prevention : deeadlock 발생 4가지 조건중 하나라도 안되도록 하는 방법 1) mutual exclusion : resource를 sharable하게 만듬 2) hold and wait : 실행전에 필요한 resource들을 모두 요청하게 한다. 3) No preemption : process가 자원들을 점유하다가 즉시 할당할수 없는 자원을 요청하면 현재 점유되고 있는 자원들이 released 4) circular wait : 모든 자원 타입들에 전체적인 순서를 부여하여 각 process가 열거된 순서대로 자원을 요청하도록 요구. *Deadlock Avoidance : 자원이 어떻게 요청될지에 대한 추가 정보를 요구, 프로세스의 요청과 방출에 대한 완전한 순서를 파악함으로써 교착상태를 피하기 위해서 process의 대기여부 결정 safe state : 시

다중 프로그래밍 실현을 위해 메모리에 많은 process들을 동시에 유지 *Address Binding Time compile time binding : 만일 process가 memory내에 들어갈 위치를 컴파일 시간에 미리 알수 있다면 컴파일러는 절대코드를 생성가능 load time binding : 이진코드를 재배치 가능 코드로 만듬 execution time binding : process가 실행하는 중간에 memory 내의 한 segment에서 다른 segment로 옮겨질수 있다면 바인딩이 실행시간까지 허용되었다고 함 *Logical vs Physical Address logical address : cpu가 생성하는 주소 physical address: 메모리가 취급하는 주소 compile-time binding과 load-time binding에서는 logical addr = physical addr execution-time binding은 logical addr != physical addr *MMU(Memory Management Unit)  virtual(logical) addr -> physical addr *Dynamic Loading  각 routine이 재배치 가능 상태로 디스크에 대기하다가, 필요할때 적재. 사용되지 않는 routine은 적재 되지 않는다. *Dynamic Llinking linking이 실행시간 까지 미루어짐. 라이브러리를 부르는 곳마다 stub이 생겨서 메모리를 찾는방법과 없을경우 라이브러리 적재방법을 알려준다. *Swapping  일시적으로 process를 main memory에서 disk로 이동시켰다가 다시 memory로  이동시키는것. 목적 : process들을 실행하는데 필요한 공간이 physical memory공간을 초과할때 사용 roll in, roll out : 더 높은 우선순위의 process가 swap-in 되고 더 낮은 우선순위의 procss가 swap-out 되는것 * Contiguous

Summary application이 Facebook, Github 같은 HTTP 서비스에 대한 사용자 계정에 접근을 할수 있도록하는 인증 framework. 사용자 인증을 사용자 계정을 호스팅하고 있는 서비스에 맡기고 third-party application에게 사용자 계정에 대한 정보에 접근 할수 있도록 권한을 부여 web app, desktop app, mobile app에게 authorization flow를 제공해줌 참고 Grant Type : Authorization Code 유저에게 인가요청 유저가 인가허가 Auth Server는 Client에게 authorization code 부여 Client는 access token을 Auth Server에 요청 Auth Server는 Client에게 token 전달 Grant Type : Implicit 위 과정 3번과정을 다음과 같이 변경 Auth Server에서 Access Token과 함께 redirection URI 전달 redirection URI로 이동하여 token 획득 client에서 token extract 스크립트를 브라우저로 전달 브라우저에서 Client로 token 전달 Grant Type : Resource Owner Password Credentials username과 password를 app에서 username과 password를 입력받아서 인가서버에 보내서 토큰 획득 다른 방식이 안될때만 사용권장, app이 user에 의해 신뢰가 될때만 사용(e.g. 앱 자체가 Auth service에 의해 소유될때) Grant Type : Client Credentials app 자체의 credentials(client id, client secret) 를 Auth Server에 보내서 Access Token을 획득 app이 redirect URI에 대한 정보를 업데이트 하고 싶다거나, api를 통해서 app 자체의 데이터를 받아고고 싶을 때 사용이 가능하다.

1. 프로젝트 루트폴더에 .travis.yml 파일을 생성한다. 2. .travis.yml 파일을 다음과 같이 작성한다. 로그인 echo "$DOCKER_PASS" | docker login -u "$DOCKER_USER" --password-stdin   현재 경로에 있는 DOCKERFILE build & push docker build --tag kimwithglasses/safe-place-db:0.0.1 . && docker push kimwithglasses/safe-place-db 경로 이동하여 gradle project build & push cd SafePlaceAPI && ./gradlew bootJar && docker build --tag kimwithglasses/safe-place-api:0.0.1 .  && docker push kimwithglasses/safe-place-api 3. 위의 경우는 password가 노출되어있기 때문에 암호화를 진행한다. .travis.yml이 있는 경로로 이동 DOCKER_PASS 변수 암호화 travis encrypt DOCKER_PASS=" password " --add --com 4. 최종 완성된 .travis.yml 파일의 모습은 다음과같다.

 내가 정의한 커스텀 MySql 이미지와 Spring Boot 서버를 docker-compose를 실행하는데 Connection Link Failure에러가 자꾸 났다. 원인은 의외의 곳에 있었다.  커스텀 MySql 이미지가 다 실행되기도 전에 Spring Boot 서버가 실행되었기 때문이다. 사실 depends_on: - safe-place-db   구문이 실행되면 실행의 순서가 보장되리라고 생각했는데, 실제로는 safe-place-db가 up 될때까지 보장해주는 것이었다. up이 된 순간 부터는 두가지 컨테이너가 동시에 실행되는 것이다. 따라서 docker-compose.yml에    restart: on-failure:10  을 추가하여 수정했다. 추가한 구문은 실패할때 10번까지 재실행을 허용하라는 의미이다. 보통 safe-place-db에서 sql 스크립트에대한 실행이 없을때는 depends on 구문으로 충돌이 나는 경우는 없지만 이번 경우는 달랐다. 완성된 docker-compose.yml 은 다음과 같다.

 Spring Boot 2.x 버전의 앱을 JAR로 패키징하는데 꽤나 많은 시간을 소비하였는데, 2.x 이전버전의 경우를 시도하다 보니 시행착오를 많이했다. 스택오버플로우 에서 찾아보면서 꼼꼼히 읽는 훈련을 계속 해야겠다. 해답은 간단했다. https://stackoverflow.com/a/52404325/8276700   Spring Boot 2.x 버전에서 bootJar과 bootWar 이라는 gradle task가 app을 패키징하는 역할을 한다. bootJar task는 실행가능한 jar file을 만드는데 책임을 지고 이는 java plugin이 적용이 될때 자동으로 생성된다고 한다. 따라서 build.gradle 파일에 다음 라인을 추가해야한다. plugins {     id 'java'     id 'org.springframework.boot' version '2.3.4.RELEASE' } 그리고 루트 디렉토리에서  ./gradlew bootJar  을 입력하면 build/libs 폴더에 jar 파일이 생성된다. 유사하게 bootWar는 executable war file을 생성하고 war plugin이 적용될때 동작한다. $./gradlew bootWar  을 입력하여 실행할수 있다.