2015. 2. 25. 17:58

MS-SQL 실행계획 Nested Join Merge Join 문제 해결 



문제: 

운영계서버와 테스트서버의 쿼리 속도가 다르다. 실제 0.5 초도 안걸리는 쿼리인데, 운영계서버에서 5초이상 걸리는 문제가 발생하였다.


확인사항:

1. 버전의 문제로 소스가 운영계와 테스트 소스가 다른가?   같음

2. 쿼리의 문제인가?  맞음. 운영계가 5초이상 걸리는 문제 발생

3. 실행계획 비교.  운영계에서 nested join 발생. 


수정사항:

nested join 을 hint 를 통해 merge join 으로 변경   ->  해결 ( 테스트서버의 실행계획과 같음)


완벽한 방법인가?

hint 는 테이블의 조인방법과 조인순서를 결정한다고 한다.

hint 의 단점이 있을까? 아직은 단점이 무엇인지 잘 모르겠다.


알아두기

hint 는 merge join 을 사용 했는데 merge join 은 두테이블을 정렬한 다음에 두 집합을 병합(merge) 하면서 조인을 수행하는 것인데, 여기서 병합알고리즘을 사용한다.

두테이블을 정렬해서 사용한다면, union 을 통해  각 테이블을 조회 한 뒤에  조인하는 방식으로 사용 하면 병합과 같은 효과를 낼 수 있다.


추가내용

옵티마이저는 데이터에 양, index 에 달라질 수 있다.  두 서버의 데이터를 동일하게 맞추고, Index 도 맞췄는데 옵티마이저가 다르게 동작 했다. 이런...또 어떤 경우에 달라지는지 찾아보자.

*MS-SQL 에서는 EXEC SP_HELPINDEX 테이블명을 통해 index 를 볼 수 있다.

 hint 는 옵티마이저 업그레이드시에 hint 를 따라 가기 때문에 문제가 될 가능성이 있다. 쿼리 수정으로 하는게 좋음.




참조

-- join 설명 http://302.pe.kr/137

-- union 으로 변경  http://otep.tistory.com/70

-- 옵티마이저 공부 http://wiki.gurubee.net/pages/viewpage.action?pageId=26744562





'2019년 이전 정리 > DB_MSSQL' 카테고리의 다른 글

[MSSQL] LEFT OUTER JOIN 예제  (0) 2014.02.13
[SQL] dateadd 문법  (0) 2014.02.10
Posted by hoonihoon
2014. 12. 12. 15:41

android studio  단축키 정리 잘된 곳




http://www.developerphil.com/android-studio-tips-of-the-day-roundup-1/


http://www.developerphil.com/android-studio-tips-of-the-day-roundup-2/

Posted by hoonihoon
2014. 12. 3. 16:37

아래와 같은 솔루션을 이용하자.


setonItemselectedListener 전에  setselection(position, false); 를 넣으면 된다.



The use of Runnables is completely incorrect.

Use setSelection(position, false); in the initial selection before setOnItemSelectedListener(listener)

This way you set your selection with no animation which causes the on item selected listener to be called. But the listener is null so nothing is run. Then your listener is assigned.

So follow this exact sequence:

Spinner s = (Spinner)Util.findViewById(view, R.id.sound, R.id.spinner);
s.setAdapter(adapter);
s.setSelection(position, false);
s.setOnItemSelectedListener(listener);


Posted by hoonihoon
2014. 12. 3. 14:32

volley post get 방법


출저  : http://stackoverflow.com/questions/16626032/volley-post-get-parameters


For the GET parameters there are two alternatives:

First: As suggested in a comment bellow the question you can just use String and replace the parameters placeholders with their values like:

String uri = String.format("http://somesite.com/some_endpoint.php?param1=%1$s&param2=%2$s",
                           num1,
                           num2);

StringRequest myReq = new StringRequest(Method.GET,
                                        uri,
                                        createMyReqSuccessListener(),
                                        createMyReqErrorListener());
queue.add(myReq);

where num1 and num2 are String variables that contain your values.

Second: If you are using newer external HttpClient (4.2.x for example) you can use URIBuilder to build your Uri. Advantage is that if your uri string already has parameters in it it will be easier to pass it to the URIBuilder and then use ub.setQuery(URLEncodedUtils.format(getGetParams(), "UTF-8"));to add your additional parameters. That way you will not bother to check if "?" is already added to the uri or to miss some & thus eliminating a source for potential errors.

For the POST parameters probably sometimes will be easier than the accepted answer to do it like:

StringRequest myReq = new StringRequest(Method.POST,
                                        "http://somesite.com/some_endpoint.php",
                                        createMyReqSuccessListener(),
                                        createMyReqErrorListener()) {

    protected Map<String, String> getParams() throws com.android.volley.AuthFailureError {
        Map<String, String> params = new HashMap<String, String>();
        params.put("param1", num1);
        params.put("param2", num2);
        return params;
    };
};
queue.add(myReq);

e.g. to just override the getParams() method.

You can find a working example (along with many other basic Volley examples) in the Andorid Volley Examples project.



출저  : http://stackoverflow.com/questions/16626032/volley-post-get-parameters

Posted by hoonihoon
2014. 11. 27. 15:10




주제:   안드로이드에서 로그인 관련 기능 중에 핸드폰 고유값을 서버에 전송할 수 있을지 알아 보았다.


분석:    아래와 같은 코드로 핸드폰 고유의 값 3가지를 가져올수 있다.


TelephonyManager telephonyManager = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);


// IMEI 

Log.d("kth", "telephonyManager.getDeviceId(); " + telephonyManager.getDeviceId());

// 핸드폰 번호

Log.d("kth", "telephonyManager.getLine1Number(); " + telephonyManager.getLine1Number());


// UDID 

String deviceId= Secure.getString(G.mainactivity.getContentResolver(), Secure.ANDROID_ID); 

Log.d("kth", "deviceId: " + deviceId);


결론:  위에 사용 되는 코드는 모두 서버로 전송하면 안된다. 


[테스트 내역]


1. IMEI 수집시에 압수수색  http://www.asiae.co.kr/news/view.htm?idxno=2010083114402683628

    md5 암호화해도 불법.


2. 폰 번호 수집  불법  

  http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_QnA_etc&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=3188


3. 다비이스 고유값 (UDID)

   애플에서 UDID 값 수집시 마켓 등록 거절.



다른방법 :  GCM에서 생성해준 디바이스key 값을 이용하는 방법으로 선택.

                단, 어플을 지우고 새로 받으면 디바이스 key 값을 새로 받기 때문에 주의해야 한다.

Posted by hoonihoon
2014. 8. 14. 13:28

※원래 쓰레드의 개념과 사용법에 대해 처음 공부하시는 분들을 위해 굉장히 상세히 포스팅 할 예정이었으나 역시 단순한 포스트에 모든 내용을 실을 수 있을 정도로 세상은 만만치 않았습니다.ㅡㅡ;;; 그림 한장 없이 텍스트로만 , 그것도 상세히가 아닌 띄엄띄엄 포스팅하게 되어서 안타깝습니다. 너무 판을 벌려서 정리가 안되는군요;;;;

1. 쓰레드의 의미
쓰레드(Thread)란 무엇인가?
아직 쓰레드 프로그래밍을 해보지 않은 사람이라면 가끔 이런 생각을 해봤을 것이다. '프로그램을 만들 때 하나의 프로그램에서 동시에 두가지 이상의 작업이 이루어지게 하려면 어떻게 해야할까?' 

예를들어 "음악이 흐르는 포토뷰어" 라는 프로그램을 생각해보자. 사진을 감상하는 프로그램인데 사진만 감상하긴 좀 밋밋해서 배경으로 음악을 깔고 싶어졌다. 사진을 보면서 음악을 듣는 것에 그치는게 아니라 사진을 넘기고 음악을 바꾸는 작업이 동시에 이루어져야 한다면? 

분명 지금까지의 만들어본 프로그램은 main 함수라는 하나의 흐름에 의해 모든것이 이루어 졌을 것이다. 하지만 이젠 사진도 흘러가야하고 음악도 흘러가야 하게 된 것이다. 이렇게 하나의 프로그램 안에 둘 이상의 흐름을 가진 프로그램을 만들 때 우리는 쓰레드를 이용한다.

2. 쓰레드와 멀티프로세스의 차이점
둘 다 두가지 이상의 작업을 동시에 처리할 수 있는 매커니즘이다. 하지만 분명 차이가 있다. 

우선 프로세스(process)에는 프로세스를 이루는 몇가지 영역이 있는데 보통 Code영역,Data영역,Heap영역,Stack영역으로 구성된다. 이것들이 모여 하나의 프로세스가 된다. 멀티프로세스가 이 같은 프로세스를 통째로 여러개 수행시키는 것이라 한다면 쓰레드는 하나의 프로세스 옆에 붙어 기생(ㅡㅡ;) 하며 수행되는 놈 쯤이 되겠다. 

쓰레드는 프로세스가 가진 Code,Data,Heap 영역을 프로세스와 공유한다. 오직 Stack만 따로 가지고 있는 놈을 쓰레드라고 부른다. 아무래도 공유하는 영역을 가지다보니 하나의 프로세스에 붙어있는 여러 쓰레드간, 혹은 프로세스와의 통신에 별다른 부담이 없다. 멀티프로세스에서는 프로세스간에 통신을 하기 위해서 IPC를 통해서 통신이 가능하다. 그리고 프로세스를 통째로 여러개 돌리면 쓰레드보다 시스템의 부하가 많이 걸릴것이다. 

여튼 우리는 쓰레드가 프로세스의 Stack영역을 제외한 나머지 영역을 공유한다는 사실 정도만 알고가자.

3. Lock과 Monitor에 대하여
쓰레드는 위에서 말했듯이 동시에 2가지 이상의 흐름을 갖는 것을 의미한다. 하지만 문제가 되는경우가 몇가지 있다. 그중 하나가 자원공유에 관한 것이다. 

만약 A라는 쓰레드가 money라는 변수의 값을 변경한다고 하자. money가 100원이라는 값을 가지고 있는데 A가 여기에 50원이라는 값을 넣으려고 한다. 우선 'money + 50원'을 해서 150원 이라는 값을 얻었다. 이제 money에 150원이라는 값을 대입하기만 하면 된다. 근데 그때 B라는 쓰레드가 money에 100원을 더 넣은 것이다. B는 200원이 되었을 거라 생각했다. 물론 200원이 되었다. 근데 그 바로 직후에 A쓰레드가 150원이라는 값을 money에 대입한것이다. A는 당연히 150원이 있는걸로 알고 있지만 B는 분명 200원이어야 할 money가 150원으로 둔갑한 것에 대해 기겁하게 되는 것이다.

그렇다. 두개의 쓰레드가 동시에 도는것은 좋은데 하나의 자원(money)을 무분별하게 사용하다보니 이런일이 벌어진 것이다. 
Lock과 Monitor란 이런 문제를 해결하기 위해 등장한 것이다. Monitor는 하나의 쓰레드가 하나의 객체에 대한 락을 획득했을 때 다른 쓰레드가 그 객체에 접근하여 동기화 시킨 영역에 접근하는 행위를 막아준다.

일단 이렇게 일이 처리되면 위의 예에서 A가 먼저 money를 사용중이기에 B는 money에 100원을 추가할 수가 없다. A가 작업이 끝나고 150원이 된 후에 B가 100원을 추가해 결국 250원을 만들 수 있는것이다.

이런 Lock을 mutual exclusion lock, 뮤텍스락이라고도 부르며 한국말로는 상호배제락이라 부른다. 그리고 이러한 락에 의해 쓰레드와 공유자원사이의 상호작용을 제어하는 행위를 동기화(synchronization)라고 부른다.

4. Monitor
Java의 오브젝트에는 Monitor가 할당된다. 이 모니터는 자신을 소유한 쓰레드를 제외한 다른 쓰레드의 접근을 막는다. 이러한 특성을  mutual exclusion 혹은 뮤텍스라고 부른다. 이렇게 모니터는 일시적으로 다른 쓰레드가 외부에서의 접근을 포기하게 만드는 기능을 하는데 만약 쓰레드가 어떤 오브젝트의 락을 획득하면 그 락을 획득한 동기화 영역에는 다른 쓰레드의 접근이 불가하다. 다른 쓰레드가 이 오프젝트의 락을 획득하기 위해서는 이전 쓰레드가 잡고있는 락을 풀어줘야지만 락의 획득이 가능하다. 이는 wait같은 대기모드 함수를 호출하거나 동기화 블록이 끝나는 부분에서 락을 자동으로 해제하게 된다.
< JAVA Whitre Paper 문서에서 발췌 - The most basic of these methods is synchronization, which is implemented usingmonitors. Each object in Java is associated with a monitor, which a thread can lock or unlock. Only one thread at a time may hold a lock on a monitor. The synchronized statement computes a reference to an object; it then attempts to perform a lock action on that object's monitor and does not proceed further until the lock action has successfully completed.>

5. 데드락
여러 회사의 면접 질문으로 굉장히 많이 나오는 데드락.
A라는 쓰레드가 특정 객체의 락을 얻게되면 그에 따른 자원을 block 하게 된다. 근데 그 쓰레드가 자신의 작업을 처리하기 위해 외부의 자원이 필요로 하는 경우가 생기게 된다. 다행이 그 자원이 누구나 접근 가능한 상태라면 불러와서 사용할 수 있지만 만약 B라는 쓰레드가 그 자원에 락을 걸고 있다면 A쓰레드는 B가 락을 해제 할 때 까지 기다리는 수밖에 없을 것이다. 설상가상으로 B 또한 A가 block하고 있는 자원을 원하고 있다면 A와 B는 서로가 Lock을 풀때까지 무한정 기다리게 되는데 이러한 상태를 데드락(Dead Lock)이라고 부른다.
이 데드락을 해결하는 방법은 데드락이 발생하기 않게 프로그래밍 하는 방법이 가장 좋다고 밖에 할 수 없다. 그외에 쓰레드의 우선순위에 따라 하나의 쓰레드를 포기하는 방법이 있는데 이러한 해결책은 프로그램의 성능저하의 큰 원인이 될것이다.
데드락이 발생하는 코드를 짜보는 것도 좋을듯...(왜!!;;)

6. 동기화(synchronized)
- 함수 이름 앞에 쓰이는 synchronized는 synchronized(this)와 동일함
- synchronized(instance) 와 synchronized(Class)와의 차이 
   => http://pupustory.tistory.com/149
- 블록으로 동기화를 사용할 때 synchronized()의 인자로 들어가는 객체는 그 객체를 Lock에 의해 보호하겠다는 말씀
- synchronized의 블록의 의미는 그 블록의 코드가 끝날때 까지 인자로 받은 객체의 Lock을 풀지 않겠다는 의미
- A라는 쓰레드가 Lock을 건 객체를 B라는 쓰레드가 그 객체의 동기화 블록외의 코드를 접근 가능하다. 즉 Lock을 건다는 말은 그 객체의 전체에 락을 거는것이 아니라 동기화 영역에 대해서만 락이 걸린다는 의미
- 꼭 Lock이 걸려있는 객체가 어떤일을 해야만 하는것은 아니다. 마치 동기화를 위한 변수처럼 사용이 가능하다.
   => http://iilii.egloos.com/4071694

7. wait/notify (작업순서)
하나의 synchronized된 자원을 두개이상의 쓰레드가 사용할 때는 하나의 쓰레드가 모든 작업이 끝난 이후에 다음 쓰레드가 작업을 시작하는 것이 아니라 때론 블록된 단위별로 번갈아 가면서 사용해야 할경우가 있다. 이럴때 현재의 쓰레드의 락을 잠깐 해제하고 대기 중이던 쓰레드를 깨워서 사용하는 과정이 필요한데 이러한 과정을 가능하게 하는 함수가 wait() 과 notify() 함수이다.

- wait()에 걸리면 그 코드를 수행하고 있던 쓰레드를 휴지상태(sleep)상태로 만들어줌. 그자리에서.
- wait()과 동시에 쓰레드가 대기상태로 돌아가면서 인자로 받은 객체에 걸고있던 Lock을 해제하게 됨
- 다른 쓰레드가 위의 객체에 Lock을 가지게 되고 작업이 끝나면서 notify()호출해서 휴지상태로 대기하고 있던 쓰레드를 깨워줌
- 단, notify()가 호출된다고 바로 대기 쓰레드가 시작되는게 아니라 지금 수행되던 쓰레드의 synchronized 블록이 끝나야지 대기중이던 쓰레드가 실행된다.
- 대기 쓰레드가 실행될 때는 그 쓰레드가 다시 객체에 대한 Lock을 가지며 wait() 코드 다음 코드부터 시작된다.

그밖에 쓰레드의 상태를 관리하는 함수들이 있다. 그 쓰레드의 상태와 이를 관리하는 함수는 다음의 링크에서 확인 할 수 있다.
=> http://www.javastudy.co.kr/docs/jm/jm15.html
=> http://www.javastudy.co.kr/docs/lec_java/thread/t2.html

8. 쓰레드 사용방법
- 아.. 결국 포스팅이 귀찮아져 이렇게 긁어 오기를 해버리는구나.. ;;;;
   => http://signpen.net/blog/106 
   => http://blog.daum.net/bifrost0076/5882414

add) 세마포어
 .. A사의 2차 면접에 나왔던 질문. OS질문 하더니 갑자기 세마포어에 대해 묻더라.. 모니터와 유사한 개념이지만 조금은 다르다. 카운터를 설정할 수 있는 세마포어도 있고 .. 조금 다르긴한데 시간을 두고 포스팅하자.. 쓰레드 포스팅을 정리하는데 너무 많은 시간과 노력을 투자해버려서 이젠 보기도 싫다.



참조  : http://openparadigm.tistory.com/30

'좋은 설계자 & 좋은관리자 & 좋은개발자' 카테고리의 다른 글

뮤택스 세마포어  (0) 2014.08.14
Posted by hoonihoon
2014. 8. 14. 10:47

1. 뮤텍스 기본 정의 


뮤텍스는 한 번에 하나의 쓰레드만이 실행되도록 하는 재 입장할 수 있는 코드 섹션에 직렬화된  접근이 가능하게 할 때 사용됩니다. 뮤텍스 객체는 제어되는 섹션에 하나의 쓰레드만을 허용하기 때문에 해당 섹션에 접근하려는 다른 쓰레드들을 강제적으로 막음으로써 첫 번째 쓰레드가 해당 섹션을 빠져나올 때까지 기다리도록 합니다.


뮤텍스는 화장실에 들어가기 위한 열쇠로 비유할 수 있습니다. 즉 화장실에 들어갈 수 있는 열쇠를 한 사람이 갖고 있다면, 한 번에 열쇠를 갖고 있는 그 한 사람만이 들어갈 수 있습니다. 화장실에 열쇠를 갖고 있는 사람이 들어가 볼일을 다 본 후에는 줄을 서서 기다리고 있는(대기열-큐) 다음 사람에게 열쇠를 주게 됩니다.  



세마포어는 공유 리소스에 접근할 수 있는 최대 허용치만큼 동시에 사용자 접근을 할 수 있게 합니다. 쓰레드들은 리소스 접근을 요청할 수 있고 세마포어에서는 카운트가 하나씩 줄어들게 되며 리소스 사용을 마쳤다는 신호를 보내면 세마포어 카운트가 하나 늘어나게 됩니다.


뮤텍스는 값이 1인 세마포어입니다.

 

세마포어는 빈 화장실 열쇠의 갯수라고 보면 됩니다. 즉, 네 개의 화장실에 자물쇠와 열쇠가 있다고 한다면 세마포어는 열쇠의 갯수를 계산하고 시작할 때 4의 값을 갖습니다. 이 때는 이용할 수 있는 화장실 수가 동등하게 됩니다. 이제 화장실에 사람이 들어갈 때마다 숫자는 줄어들게 됩니다. 4개의 화장실에 사람들이 모두 들어가게 되면 남은 열쇠가 없게 되기 때문에 세마포어 카운트가 0이 됩니다. 이제 다시 한 사람이 화장실에서 볼일을 다 보고 나온다면 세마포어의 카운트는 1이 증가됩니다. 따라서 열쇠 하나가 사용가능하기 때문에 줄을 서서 기다리고 있는 다음 사람이 화장실에 입장할 수 있게 됩니다.


2. 언제 사용하나요?


Process 혹은 Thread 간의 communication / 통신 시에 shared memory (공유 메모리) 등을 쓰는 경우에 하나의 자원 (Resource or memory or even files) 에 두 개 이상의 process or thread 가 write 을 하는 경우에 문제가 발생한다. 이를 방지하기 위해 하나의 process 혹은 thread 만이 resource 에 접근하여 write 을 할 수 있도록 제어해 주어야 하고, 이 때에 Mutex 혹은 Semaphore 를 사용한다. Thread 에서는 MuTex 를 사용하고, Process 에서는 Semaphore 를 사용한다.




3. 뮤텍스 상세

공유 자원에 대한 접근 제어 

다수의 객체가 공유 자원에 접근하려고 하면, (공유 자원의 종류에 따라서)접근 시점을 동기화 시켜줄 필요가 생긴다. 여기에서 동기화란 시간과 공간을 맞추어 준다는 의미로, 즉 공유 자원 영역 (공간)에 접근하는 객체들의 진입 시간을 제어할 수 있어야 함을 의미한다.

멀티 Thread(쓰레드) 프로그램 역시 공유 자원에 여러 개의 쓰레드가 접근할 수 있으므로 공유 자원 영역에 대한 동기화가 필요 하다.

카운팅 프로그램을 예를 들어 보자. 카운트 변수는 전역:::변수(:12)로 A,B 두개의 쓰레드가 공유하면서, 1씩 증가하는 카운팅 정보를 유지하기 위해 사용된다. 공유 자원 영역 즉 "count 값을 읽어 오고, 연산을 해서 저장하는" 영역에 대한 쓰레드간 동기화가 이루어지지 않는 다면 아래와 같은 일이 발생할 수 있을 것이다.
  1. global int count = 0
  2. A 쓰레드가 count값 0을 읽는다.
  3. B 쓰레드가 count값 0을 읽는다.
    • A 쓰레드가 카운팅 연산을 하기 전에 B쓰레드가 접근해 버린 상황이다.
  4. A 쓰레드가 count+1 연산을 하고 값을 쓴다. count = 1
  5. B 쓰레드가 count+1 연산을 하고 값을 쓴다. count = 1
A와 B쓰레드가 한번씩 카운팅 연산을 했으므로, count값은 2가 되어야 하겠지만, 실제로는 1이 저장되어 버렸다.

이러한 문제의 해결을 위해서 쓰레드를 동기화 시켜줄 필요가 있다..


일반적으로 동기화는 "공간과 시간"을 제어하는 방식으로 이루어진다. 즉 "접근 제어가 필요한 공간"을 지정하고 지정한 "공간에 진입 할 수 있는 시간"을 제어하는 방식이다.


여기에서 "접근 제어가 필요한 공간"에는 보호 해야 할 공유 자원이 놓인다. 보호 해야할 공유 자원이 있는 공간을 임계 영역이라고 한다. 시간 제어는 해당 임계 영역에 동 시간에 단지 하나의 쓰레드만 접근하도록 제한 하는 방식으로 이루어진다.


임계영역에 들어가기 위한 하나의 키를 가지고 경쟁하는 것으로 이해하면 된다. 임계영역에 들어가기 위한 키는 단지 하나 밖에 없으므로 어떤 스레드가 키를 얻어서 임계영역에 진입하면, 다른 스레드는 키를 얻을 때까지 - 앞서 임계영역에 진입한 프로세스가 키를 되돌려줄 때까지 - 기다려야 한다.


 

위의 카운팅 프로그램을 예로 설명해보자. 임계 영역은
  1. count 값을 읽어와서
  2. 카운팅 연산을 하고
  3. 연산 결과를 저장하는
코드 영역으로 지정할 수 있을 것이다.


이 임계 영역에는 오직 하나의 쓰레드만이 진입할 수 있다. 즉 쓰레드 A가 임계 영역에 진입해서 코드를 수행중에 있다면 쓰레드 B는 임계 영역 밖에서 기다려야 한다. 이렇게 쓰레드를 동기화 시킴으로써, 아래와 같이 제대로된 카운팅 연산을 보장할 수 있게 된다.
  1. global int count = 0;
  2. A 쓰레드가 임계 영역에 진입
  3. B 쓰레드도 임계 영역 진입을 시도하지만, A 쓰레드가 진입해 있으므로 임계 영역 밖에서 대기한다.
  4. A 쓰레드가 count 값을 읽고
  5. 카운팅 연산을 해서
  6. 값을 저장한다. count = 1
  7. A 쓰레드가 임계 영역에서 빠져나온다.
  8. 비로서 B 쓰레드가 임계 영역에 진입해서
  9. count 값 1을 읽어서 카운팅 연산을 하고 저장한다. count = 2
제대로 카운팅 연산이 되는걸 확인할 수 있다.

Mutex 

뮤텍스는 pthread에서 제공하는 동기화 매커니즘으로 공유 자원 공간에 대한 접근 시간 제어로 동기화를 달성한다. 기본적인 매커니즘은 세마포어(:12)와 비슷하다. 특히 POSIX(:12) 세마포어와 비슷하며, 동기화 매커니즘으로 뮤텍스 대신 세마포어를 사용할 수도 있다. 동기화 매커니즘의 핵심은 상호 배제로 다음과 같이 달성 한다.

global int v = 1;
lock()
{
    while(1)
    {
        if (v==1)
            break;
    }
    v = 0;
    return 1;
}

unlock()
{
    v = 1;
    break;
}
어디까지나 매커니즘 상으로 그렇다는 얘기고, 세마포어와 마찬가지로 busy wait 상태에 놓이지 않음을 보장한다.

상호 배제는 잠금 형식으로 이루어진다. 쓰레드는 잠금 v를 얻어야 임계 영역에 진입할 수 있다. 임계 영역을 빠져나오면 잠금을 되돌려 줘서 다른 쓰레드가 잠금을 얻을 수 있도록 한다.

뮤텍스 메커니즘의 특징을 정리했다.

  • Atomicity - mutex 잠금(lock)는 최소단위 연적(atomic operation) 으로 작동한다. 이말의 뜻은 하나의 쓰레드가 mutex 를 이용해서 잠금을 시도하는 도중에 다른 쓰레드가 mutex 잠금을 할수없도록 해준다는 뜻이다. 한번에 하나의 mutex 잠금을 하도록 보증해준다.
  • Singularity - 만약 스레드가 mutex 잠금을 했다면, 잠금을 한 쓰레드(:12)가 mutex 잠금을 해제 하기 전까지 다른 어떠한 쓰레드도 mutex 잠금을 할수 없도록 보증해준다.
  • Non-Busy Wait - 바쁜대기 상태에 놓이지 않는다는 뜻으로, 하나의 쓰레드가 mutex 잠금을 시도하는데 이미 다른 쓰레드가 mutex 잠금을 사용하고 있다면 이쓰레드는 다른 쓰레드가 락을 해제하기전까지 해당 지점에 머물러 있으며 이동안은 어떠한 CPU 자원도 소비하지 않는다 (이를테면 sleep). 

뮤텍스 만들기 

뮤텍스를 생성하기 위해서 우리는 먼저, 뮤텍스정보를 저장하기 위한 타입인 pthread_mutex_t 를 선언해주고 이것을 초기화 해주어야 한다. 선언과 초기화의 가장간단한 방법은 PTHREAD_MUTEX_INITIALIZER 상수를 할당하는 것으로 아래와 같이 사용할수 있다.
pthread_mutex_t a_mutex = PTHREAD_MUTEX_INITIALIZER;

혹은 pthread_mutex_init(3)함수로 뮤텍스를 생성할 수도 있다.
#include <pthread.h>

int pthread_mutex_init(pthread_mutex_t * mutex, const pthread_mutex_attr *attr);
;;;


뮤텍스 잠금, 잠금해제, 제거 

뮤텍스 잠금을 위한 함수로는 pthread_mutex_lock() 함수를 제공한다. 이 함수는 해당 뮤텍스에 대해서 잠금을 시도하는데, 만약 잠그려는 뮤텍스가 다른 쓰레드에 의해서 이미 잠겨있다면, 잠금을 얻을수 있을때까지 - 이미 잠근 다른 쓰레드가 뮤텍스의 잠금을 해제할때까지 - 봉쇄(블럭)되게 된다. 다음은 이러한 뮤텍스 잠금을 얻기 위한 지원함수들이다.
int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_trylock(pthread_mutex_t *mutex);
int pthread_mutex_destory(pthread_mutex_t *mutex);

pthread_mutex_trylock() 를 사용하면 잠금을 얻을수 없을경우 해당 코드에서 블럭되지 않고 바로 에러코드를 돌려준다. 즉 pthread_mutex_lock 의 비봉쇄 버젼이라고 생각하면 된다.

뮤텍스 잠금을 얻은후 해당 영역에서의 작업을 마친후 잠금을 해제하기 위해서 사용한다. 사용되는 함수는 pthread_mutex_unlock(3) 이며 함수원형은 다음과 같다.
int pthread_mutex_unlock(pthread_mutex_t *mutex);
다음은 쓰레드간 공유되는 자원을 위해서 잠금을 어떻게 사용하는지를 보여주는 간단한 예제다.

예제: mutex_lock.c
#include <stdio.h>  
#include <unistd.h>  
#include <pthread.h>  
 
int ncount;    // 쓰레드간 공유되는 자원 
pthread_mutex_t  mutex = PTHREAD_MUTEX_INITIALIZER; // 쓰레드 초기화 
 
void* do_loop(void *data) 
{ 
    int i; 
    for (i = 0; i < 10; i++) 
    { 
        pthread_mutex_lock(&mutex); // 잠금을 생성한다. 
        printf("loop1 : %d\n", ncount); 
        ncount ++; 
        if(i == 10) return;
        pthread_mutex_unlock(&mutex); // 잠금을 해제한다. 
        sleep(1); 
    } 
} 
 
void* do_loop2(void *data) 
{ 
    int i; 
 
    // 잠금을 얻으려고 하지만 do_loop 에서 이미 잠금을  
    // 얻었음으로 잠금이 해제될때까지 기다린다.   
    for (i = 0; i < 10; i++) 
    { 
        pthread_mutex_lock(&mutex); // 잠금을 생성한다. 
        printf("loop2 : %d\n", ncount); 
        ncount ++; 
        pthread_mutex_unlock(&mutex); // 잠금을 해제한다. 
        sleep(2); 
    } 
}     
 
int main() 
{ 
    int       thr_id; 
    pthread_t p_thread[2]; 
    int status; 
    int a = 1; 
 
    ncount = 0; 
    thr_id = pthread_create(&p_thread[0], NULL, do_loop, (void *)&a); 
    sleep(1); 
    thr_id = pthread_create(&p_thread[1], NULL, do_loop2, (void *)&a); 
 
    pthread_join(p_thread[0], (void *) &status); 
    pthread_join(p_thread[1], (void *) &status); 
 
    status = pthread_mutex_destroy(&mutex); 
    printf("code  =  %d", status); 
    printf("programing is end"); 
    return 0; 
} 
위의 코드를 우선 mutex 잠금을 하지 않은체 컴파일후 실행해보자. 간단하게 pthread_mutext_lock 와 pthread_mutex_unlock 부만 주석처리하면 된다. 그러면 do_loop2 와 do_loop 가 일정한 간격을 두고 ncount 자원에 접근하는 것을 볼수 있을것이다. 그러나 우리는 do_loop 가 ncount 자원을 접근하고 있는동안 다른 쓰레드가 접근하지 않기를 원할때가 있을것이다. 이럴때 뮤텍스 잠금을 사용하면 된다.

위의 코드에서 뮤텍스 잠금 부분의 주석을 풀고 다시 컴파일해서 실행시켜보면, do_loop 쓰레드가 ncount 증가 작업을 모두 마칠때까지 do_loop2 쓰레드는 해당 영역에서 블럭됨을 알수 있을것이다. 이런식으로 하나의 쓰레드가 특정자원에 접근할때 다른 쓰레드가 접근하지 못하도록(한번에 하나의 쓰레드만 해당 자원에 접근할수 있도록) 제어할수 있다.

컴파일 방법은 gcc -o mutex_lock mutex_lock.c -lpthread 이다

더이상 뮤텍스를 사용할일이 없다면 pthread_mutex_destory 를 이용해서 뮤텍스 자원을 제거(free) 하도록 한다. 만일 뮤텍스자원을 사용하는 쓰레드가 하나라도 존재한다면 에러코드(EBUSY)를 리턴한다. 그러므로 모든 쓰레드의 뮤텍스에 대해서 pthread_mutex_unlock 을 이용해서 잠겨져야만 뮤텍스 제거가 성공할수 있다. 성공할경우 0을 넘겨준다.



4. java 상세 보기

“MUTual EXclusion 으로 상호배제라고도 한다. Critical Section을 가진 스레드들의 Runnig Time이 서로 겹치지 않게 각각 단독으로 실행되게 하는 기술이다. 다중 프로세스들의 공유 리소스에 대한 접근을 조율하기 위해 locking과 unlocking을 사용한다. 즉, 쉽게 말하면 뮤텍스 객체를 두 스레드가 동시에 사용할 수 없다는 의미이다.” (from reference #1)

“제어되는 섹션에 하나의 쓰레드만을 허용하기 때문에 해당 섹션에 접근하려는 다른 쓰레드들을 강제적으로 막음으로써 첫 번째 스레드가 해당 섹션을 빠져나올 떄 까지 기다린다. 예) Niclas Winquits씨가 2005년에 쓴 화장실 비유 뮤텍스는 화장실에 들어가기 위한 열쇠로 비유할 수 있다. 즉 화장실에 들어갈 수 있는 열쇠를 한 사람이 갖고 있다면 한번에 그 한 사람만 들어 갈 수 있다. 화장실에 들어간 사람이 나오면 줄을 서서 기다리는 다음 사람(대기열-큐)에게 열쇠를 주게 된다.” (from reference #2)

Mutex Implementation in Java (from reference #4)

public Class MyClass {
  private static Object lock = new Object();
  public void myMethod() {
    // Stuff that multiple threads can execute simultaneously.
    synchronized(MyClass.lock) {
      // Stuff that only one thread may execute at a time.
    }
  }
}

MyClass 의 instance 들은 lock 이라는 object 를 공유하고 (note ‘static’), shared resource 에 write 을 하기 이전에 test and set (lock 이 free 한지 test 해보고, free 하다면 lock 을 set 하고 critical section 에 진입, critical operation 을 마치고 free lock) 을 한다. Java 의 synchronized keyword 는 thread-safe 를 guarantee 한다. (후에 Java Synchronized keyword 관련 포스팅 요망)

Semaphore 란?

” 세마포어는 리소스의 상태를 나타내는 간단한 카운터로 생각할 수 있다. 일반적으로 비교적 긴 시간을 확보하는 리소스에 대해 이용한다. 유닉스 시스템의 프로그래밍에서 세마포어는 운영체제의 리소스를 경쟁적으로 사용하는 다중 프로세스에서 행동을 조정하거나 또는 동기화 시키는 기술이다. 세마포어는 운영체제 또는 커널의 한 지정된 저장장치 내 값으로서, 각 프로세스는 이를 확인하고 변경할 수 있다. 확인되는 세마포어의 값에 따라, 그 프로세스가 즉시 자원을 사용할 수 있거나, 또는 이미 다른 프로세스에 의해 사용 중이라는 사실을 알게 되면 재시도하기 전에 일정 시간을 기다려야만 한다. 세마포어는 이진수 (0 또는 1)를 사용하거나, 또는 추가적인 값을 가질 수도 있다. 세마포어를 사용하는 프로세스는 으레 그 값을 확인하고, 자원을 사용하는 동안에는 그 값을 변경함으로써 다른 세마포어 사용자들이 기다리도록 해야한다. ” (from reference #1)

” 공유 리소스에 접근할 수 있는 최대 허용치만큼 동시에 사용자 접근을 할 수 있게 한다. 쓰레드들은 리소스 접근 요청을 할 수 있고 세마포어에서는 카운트가 하나씩 줄어들게 되며 리소가 모두 사용 중 인경우(카운트 0) 다음 작업은 대기를 하게 된다. 리소스 사용을 마쳤다는 신호를 보내면 카운트가 하나 늘어나게 되고 다음 작업이 사용 할 수 있다. 예) 세마포어는 빈 화장실 열쇠의 갯수에 비유할 수 있다. 즉 비어있는 칸 만큼 열쇠가 있다고 가정하면 사람들이 화장실에 들어갈 때 마다 열쇠의 숫자는 줄어 들게 된다. 화장실 칸이 다 찰 경우 카운트는 0이 되며 다음 사람은 줄을 서서 기다린다. 볼일을 끝내고 나오면 리소스 사용을 마쳣다는 신호로 카운트를 하나 늘이고 다음 사람에게 부여 한다. ” (from reference #2)

Semaphore Implementation in Java (needs to be updated)

- Mutex 의 구현과 유사하다. Mutex 의 경우 0과 1의 두 상태 뿐인 lock 인 대신, Semaphore 의 경우 counter 여야 하고, lock 이 true 인지 확인하는 대신 counter 가 0 혹은 max # of threads allowed (구현 방식에 따라 min or max 를 취하는 방식) 인지를 확인하여, test and set 으로 critical section 에 진입하면 counter 를 1 증가 혹은 감소시키고, shared resource 에 write 하는 등의 작업이 끝난 뒤 critical section 을 exit 하면서 counter 를 되돌린다.

e) Mutex and Semaphore

- critical section 에서 (즉, mutex 의 lock 가지고 있거나 semaphore 의 counter 를 하나 소비 중인) processing time 이 오래 걸리는 경우는 어떻게 처리하나 -> time-out 을 설정하여 이를 관리한다. (추가 조사 + 포스팅 필요)

f) Mutex vs Semaphore (from reference #1)

  1. 세마포어는 뮤텍스가 될 수 있지만 뮤텍스는 세마포어가 될 수 없다. (mutex 는 상태가 0, 1 두 개 뿐인 binary semaphore 이다)
  2. 세마포어는 소유할 수 없는 반면 뮤텍스는 소유가 가능하며 소유주가 이에 대한 책임을 진다. (mutex 의 경우 상태가 두개 뿐인 lock 이므로 lock 을 ‘가질’ 수 있다.)
  3. 뮤텍스의 경우 뮤텍스를 소유하고 있는 쓰레드가 이 뮤텍스를 해제할 수 있다. 하지만 세마포어의 경우 이러한 세마포어를 소유하지 않는 스레드가 세마포어를 해제할 수 있다.
  4. 세마포어는 시스템 범위에 걸쳐있고 파일시스템상의 파일 형태로 존재한다. 반면 뮤텍스는 프로세스 범위를 가지며 프로세스가 종료될 때 자동으로 clean up된다.
  5. ★★★ 가장 큰 차이점은 관리하는 동기화 대상이 갯수이다. 뮤텍스는 동기화 대상이 오직 하나뿐일 때, 세마포어는 동기화 대상이 하나 이상일 때 사용한다.




정리참조: 
http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Thread/Beginning/Mutex

http://www.gpgstudy.com/forum/viewtopic.php?t=6198&highlight=%BC%BC%B8%B6%C6%F7%BE%EE

http://crack-tech-interview.com/2014/01/26/semaphore-%EC%99%80-mutex-mutual-exclusion/


'좋은 설계자 & 좋은관리자 & 좋은개발자' 카테고리의 다른 글

쓰레드 정리.  (0) 2014.08.14
Posted by hoonihoon
2014. 7. 14. 11:00




1. HTTP 기본 구조(HTTP 1.0 이하)




파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정



위 그림(Wire Shake 예제)에서와 같이 HTTP는 기본적으로 Connection-Less 방식을 가진다. 즉 맷어진 Socket 연결은 유지되지 않고 매번 끊어지며다시 생성 되는 구조이다.



웹 서버 상세 처리 과정:

http://mohwaproject.tistory.com/entry/%EC%A0%95%EC%A0%81%EB%8F%99%EC%A0%81-%ED%8E%98%EC%9D%B4%EC%A7%80-%EC%9B%B9-%EC%84%9C%EB%B2%84-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95







2. Keep-Alive(HTTP 1.1 이상) 기능 이란?


위 HTTP 기본 구조를 바탕으로 맷어진 Socket 연결이 종료된 시점(HTTP Response 이후)부터 웹 서버에 정의된 Keep-Alive Timeout 까지 기존 연결(Socket)을 유지하는 기능.


즉, 정의된 시간(Keep-Alive Timeout) 내에 새로운 HTTP 요청이 발생한다면? 맷어진 Socket 연결을 지속적으로 유지할 수 있다.(앞서 말한바와 같이 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다.)



IIS 테스트 결과 정의된 시간의 50% 이상 일찍 끊어진다.(120초 / 2)







3. IIS(6 / 7) Keep-Alive 설정 방법



- IIS 6


1. Keep-Alive 활성화 설정 및 Keep-Alive Timeout 정의


연결 시간 제한은 기본 120초를 갖는다.






- IIS 7:


1. Keep-Alive 활성화 설정












2. Keep-Alive Timeout 정의


연결 시간 제한은 기본 120초를 갖는다.












4. 웹 서버 HTTP Connection 변화




- Keep-Alive 비활성화 시:


1. 아래 예제와 같이 맷어진 HTTP Connection(Socket 연결)은 유지되지 않고 바로 끊어진다.(Current Connection 0.000)


2. Response-Header Field인 Connection 값으로 "close" 를 응답한다.








- Keep-Alive 활성화 시:


1. 아래 예제에서와 같이 맷어진 HTTP Connection(Socket 연결)은 유지된다.(Current Connection 1.000)


지속적인 연결은 유지되나 정의된 Keep-Alive Timeout(120초)  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다)


2. Response-Header Field인 Connection 필드는 존재하지 않는다.(IIS 기준)










5.  Wire Shake를 통해 본 Keep-Alive 처리 과정



파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)







Keep-Alive 처리 과정


1. HTTP Session(논리적 연결) 생성




2. 정의된 Keep-Alive Timeout 내에 새로운 HTTP 요청이 발생할 경우, 새로운 Socket을 재 생성하는 것이 아닌 활성화 된 Keep-Alive 기능을 통해 유지된 Socket 연결 Request하게 된다.


즉, Socket 연결에 필요한 모든 비용이 감소하게 되며, 그에 따라 전체적인 성능도 좋아지게 된다.




3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.




4. 정의된 Keep-Alive Timeout 동안 맷어진 Socket 연결은 지속적으로 유지된다.




5. HTTP Session Close


- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.






Keep Alive Timeout(연결 유지 시간) 종료 시 처리 과정



파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정


빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)


주황 테두리Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(정의된 Keep-Alive Timeout(연결 유지 시간) 종료 시  첫 번째 요청과 같이 TCP 세션 수립과정 이 다시 발생하게 된다.)


출저: http://mohwaproject.tistory.com/entry/Wire-Shake%EB%A5%BC-%ED%86%B5%ED%95%B4-%EB%B3%B8-KeepAlive-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95



TCP 세션 수립 과정



이번 포스트에서는 SSL 동작 방식에 앞서 패킷 교환 방식의 기본인 TCP 3 Way Handshake에 대해서 알아보도록 하겠습니다.



TCP 3 Way Handshake의 정의:


송신 측과 수신 측이 서로 교환할 패킷을 위해 총 3개의 패킷을 주고받으며, 서로에 대한 전송을 보장하는 세션을 수립하는 

과정입니다.




아래는 TCP 3 Way Handshake 과정을 대략적으로 도식화 한 그림 입니다.












TCP 3 Way Handshake 에 대한 상세 과정은 아래와 같습니다.






송신 측 호스트(211.254.99.210(클라이언트))

수신 측 호스트(203.242.213.203(웹서버))



1. 송신 측은 수신 측과의 통신을 원하고 있음을 알리는 신호로 TCP 헤더의 SYN(Synchoronize) Flag를 활성화(1)하고, 패킷에 일련번호(S/N(seq = 0))를 붙어 상대방에게 알려줍니다.


2. 이때 수신 측은 송신 측 SYN(Synchoronize)Flag 신호에 대한 응답 패킷 생성에 들어가기 위해, ACK(Acknowledgement)Flag를 on 시키고, 송신 측 일련번호(S/N(seq = 0))에 1을 더한 응답(A/N(ack = 1))값과 

자신의 일련번호(S/N(seq = 0))를 발송합니다. 또한, 이 과정은 송/수신 측의 양방향 세션이 수립되었음을 의미합니다.


3. 송신 측은 수신 측에게 두 번째 패킷(ack 및 일련번호(S/N(seq = 1) == (수신 측에게 받은 ack = 1 값))에 대한 응답을 주며, 이때부터 양 방향 패킷 교환이 시작되는 것입니다.






아래는 송/수신 간에 패킷 교환이 이루어지는 과정입니다.




송/수신간에 세션 수립(TCP 3 Way Handshake) 과정이 끝난 후 송신 측이 수신 측에게 GET요청을 보내고 있으며, 그에 따른 응답 메시지가 전송되고 있습니다.






위와 마찬가지로 송신 측의 GET 요청에 대한 응답 메시지가 전송됩니다.






페이지의 구성요소(js, css, img 등)이 요청됩니다.






웹서버가 클라이언트에게 HTML 응답 패킷을 전송합니다.




출저

http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD


Posted by hoonihoon