java. java.lang.Math methods

아주 간략화하여 기억하기 쉽도록 정리해보자!

- abs(x) = |x|
- cbrt() / sqrt(): cube root / square root
- ceil() / round() / floor(): 올림 / 반올림 / 버림
- exp(n) = e^n
- expml() = e^x - 1
- hypot(x, y) = sqrt(x^2, y^2)
- log(x) = ln(x)
- max() / min(): 최대 / 최소값
- pow(): 제곱수
- random(): 랜덤값
- scalb(x,n) = x^n
- signum(x): 0.0(x=0), 1.0(x>0), -1.0(x<0 br="">- toDegrees() / toRadians(): 라디안을 각도로 / 각도를 라디안으로
- 삼각함수: cos() sin() tan() 등과 acos()(아크코사인) 등등

참고 page: http://java.lang.math/

Algorithm. 실수 연산

프로그래밍 중 실수 연산이 문제가 되는 경우가 왕왕 있음.

오늘도 algorithm 문제 풀다 한번 위기에 봉착해서 오답노트겸 적어놓는다.

package com.yongk.algospot.RATIO;
import java.util.Scanner;

public class RATIO {

 public static void main(String[] args) {
  Scanner sc = new Scanner(System.in);
  int T = Integer.parseInt(sc.nextLine());
  while(T-- > 0) {
   long N = sc.nextLong();
   long M = sc.nextLong();
   System.out.println(getMinimumTick(N, M));
  }
 }

 private static long getMinimumTick(long N, long M) {
  
  long Z = (long)(1 + M * 100 / N);
  if (Z >= 100) return -1;
  return (long)Math.ceil((Z * N - 100 * M) / (100 - Z));

 }
}

위에서 틀린 것을 찾아보면..
Math.ceil에 들어가는 인자가 long으로 연산되어 double로 cast 되어 Math.ceil에 입력됨.

 private static long getMinimumTick(long N, long M) {
  
  long Z = (long)(1 + M * 100 / N);
  if (Z >= 100) return -1;
  return (long)Math.ceil((double)(Z * N - 100 * M) / (100 - Z));

 }

로 변경이 필요하다. 별 것 아닌데 개고생함.

결론:
1. 가급적이면 실수 연산을 정수 연산에 섞지 않고
2. 섞어야 한다면 캐스팅 반드시 할 것

python과 java

하도 파이선으로 스크립팅 하는 것들이 많아 궁금하기도 의무감도 들어서 검색을 하고 좀 봤는데..
한 마디로 요약하자면 매우 게으르고 발전된 언어인 것 같다.
C로 프로그래밍을 시작하고 자바를 접하면서 발전된 언어라는 것을 느꼈는데
파이선은 그보다 더 발전한 언어인것 같다

인상깊었던 것은
ㅡ 튜플
ㅡ 간단한 string 편집.. 구아바랑 비교를 함 해봐야 할 듯..
ㅡ 간단한 함수 모듈 클래스 등등 oop 구현
ㅡ 간단한 간단한 간단한.. 불필요한 반복적인 문구들 다 간단함.
ㅡ 리턴이 있는지 보이드인지도 선언 안해도 알아서 됨

진짜 게으른 언어다. 짱인듯. Pydev 설치해노코 익숙해지는것만 남았다. 되게쉽네 진짜..

repository의 개인적인 팁

프로젝트를 진행하면서 repo / git 명령을 잘못 써서 몇십G 짜리 repository를 통째로 날려본 경험이 많아 그러지 않기 위해 이것 저것 해보다 알게된 나만의 방법 몇 가지 공유한다.

1. repo rebase
repo sync에 -c 옵션을 사용하면 수정 몇 번 하고 checkout 하면 더 이상 sync가 안되고 빨간 줄이 생기는 경우가 있다. 더러는 내 branch를 이탈하는 경우도 있다.
이럴 땐 쿨하게
 $ repo rebase
하면 말끔히 해결!
물론 원하는 git만 하거나 옵션 직접 찾아보고 사용 가능하다.
<>
2. repo forall
repo sync 하다가 보면 빨간줄로 sync 안된 git 들이 보인다.
이럴 땐 하나하나 하기 보다는 나열된 git만 추려서 다음같이 하면 쉽다.
 $ repo forall -c git checkout -f
이 것을 응용하면 기타 다른 명령도 응용 가능하다.

3. repo sync
진짜 다 날리기엔 아깝고 git 하나만 날리고 다시 받아보고 싶을 땐
지워라!
그리고 그 것만 sync 하면 된다!
예를 들면,
 /source/android/$ rm kernle -rf
 /source/android/$ repo sync kernel/msm
하면 kernel/msm만 sync 하여 kernel 폴더가 다시 생김.

- git project가 엉망이 되어 origin으로 HEAD를 변경하는 방법
  - 첫 번째 방법
$ git fetch origin
$ git reset --hard origin/HEAD

  - 두 번째 방법, 문제 branch를 NEEDFIX라고 함
$ git branch temp #새로운 branch 생성
$ git checkout temp # 거기로 이동
$ git branch -D NEEDFIX #삭제
$ git checkout NEEDFIX #checkout

repository 날리고 다시 받지 말고 끝까지 써보자!

git 오류

android/kernel/: discarding 6 commits removed from upstream
project android/kernel/

It seems that I cannot create a rebase-apply directory, and
I wonder if you are in the middle of patch application or another
rebase.  If that is not the case, please
        rm -fr /home/yongk.kim/cayman_gb_mpcs/android/kernel/.git/rebase-apply
and run me again.  I am stopping in case you still have something
valuable there.

Context Switch

Context Switch (문맥 교환)

I. Context switch 이해



가. 문맥교환의 정의
- Running 상태의 Task가 사용하던 context를 메모리 특정 영역에 저장한 후 새로이 수행될 Task의 context를 PCB 또는 Stack 에서 CPU의 레지스터 영역으로 복사하여 새로운 Task가 수행되도록 하는 일련의 작업

나. 관련 개념
- Dispatching : 준비 상태의 프로세스들 중에서 우선순위가 가장 높은 프로세스에게 CPU 할당
- Time Quantum : 특정 프로세스에게 할당되는 시간의 단위, 특정 프로세스의 CPU 독점 방지
- Preemption : 타임 퀀텀이 초과하면 인터럽트를 통해 CPU 사용권을 빼앗음

II. Context switch 개념도 및 진행과정

가. 개념도
 

 
나. 진행과정 


1) 인터럽트나 시스템 호출에 의해 문맥교환 요구
2) 사용자모드 -> 운영체제 모드
3) 기존 프로세스의 현재 HW상태 정보를 PCB에 저장
4) 다음에 실행할 프로세스의 상태 정보를 PCB에서 복구한 후 다음 프로세스를 실행
5) 운영체제 모드 -> 사용자 모드

III. Context switch 과정의 오버헤드와 해결방안


가. 오버헤드 발생시점

 
 나. 해결방안

- Context Switch가 자주 발생하지 않도록 다중 프로그래밍 정도 낮춤
- 스택 중심의 시스템에서는 스택 포인터를 변경하여 프로세스간 문맥교환 수행
- Light weight 프로세스인 스레드를 이용하여 Context switch 부하 최소화 

Spin lock, live lock, dead lock

Spin lock 

크리티컬 섹션이 있고, 한 스레드가 크리티컬 섹션에 대한 lock을 소유하고 있다면 그 lock이 반환될 때 까지 계속 확인하며 기다리는 것을 의미(컨텍스트 스위칭을 하지 않고 루프를 돌면서 재시도 하는 것, Busy waiting)한다. Lock-Unlock 과정이 매우 짧아서 lock하는 경우가 드문 경우에 유용하다.

 

장점 : 잦은 컨텍스트 스위칭을 줄여서 효율을 높일 수 있다.

단점 : Lock이 길게 유지된다면 나머지 blocking 상태의 쓰레드들이 계속 무한루프를 돌아 CPU를 쓸데없이 낭비하는 경우가 생길 수 있다. 

 

Live lock

2개 이상의 쓰레드가 다른 쓰레드의 행동에 영향을 받으며 진행되는 경우, 쓰레드간의 신호가 서로 맞지 않아 신호가 맞을 때까지 진행하지 못해서 마치 행동은 일어나지만 block된것처럼 보이는 현상을 말한다.

좋은 예시를 들자면 한 길을 지나가는데 마주보는 사람이 서로 같은방향으로 계속 비켜줘서 지나가지 못하는 경우를 들 수 있다.

Dead lock

2개의 쓰레드가 동시에 lock을 건 상태에서 서로 lock이 풀리기를 기다리는 상황을 말한다. 이렇게 되면 작업이 진행되지 않고 영원히 기다리게되는 문제가 있다.

[출처] Spin lock, Live lock, Dead lock|작성자 쿨랜드