2019/09

프롤로그 필자가 프로그래밍을 하면서 가장 신경 쓰는 부분이 예외처리다. C# 관련 글에도 예외 처리를 쓴 적이 있는데 완수를 못해서 늘 마음에 걸린다. 지금은 어찌하다 보니 현 개발 프로젝트가 JAVA가 되는 바람에 상당기간 동안 JAVA를 주력 언어로 써야 한다. 그래서 C#은 나중으로 미루고 JAVA의 예외 처리를 먼저 정리해보려 한다. 이번 글에서는 JAVA의 예외 처리 Class들에 대해서 고민해보는 시간을 먼저 갖으려 한다. Throwable, Exception, Error 위 그림은 JAVA의 예외처리 Class들의 상속체계이다. 가장 super 위치에 Throwable 이 자리 잡고 (있다. 그렇다 모든 예외 처리 Class의 super base이다. 모든 예외나 에러가 이 Class로부터 ..

프롤로그 이전 글에서 교착상태가 무엇인지 이를 재현해보고 교착상태의 thread를 검출해봤다. 이번글은 명시적인 Lock을 이용하여 교착상태에 빠진 thread를 탈출시키는 방법을 제시 해보려 한다. 명시적 Lock의 사용 JAVA의 명시적인 Lock은 표준 JDK 에서 총 3가지로 제공된다. ReentrantLock, ReentrantReadWirteLock, 그리고 일전에 다루었던 StampedLock이다. 명시적인 Lock은 Java의 Object에 숨어있는 암묵적인 Lock보다 그 야말로 명확하다. 블록이 아닌 lock / unlock의 명시적인 호출로 Lock을 건다. 그렇기에 위험하기도 하다. private ReentrantLock lock = new ReentrantLock(); // 중략 ..

프롤로그 필자는 전산학을 공부했다. 요즘은 컴퓨터 공학이라고 하는데 틀린말이다. 우린 컴퓨터를 만드는 법을 배우지 않았다. 컴퓨터 사이언스가 맞다. 필자의 사견이니 학과명 변경을 주도하시고 찬성하신 "교수님들 노여워 마세요!" 왜 전공 운운 했냐면 교착상태/Dead Lock 학교다닐때 다 배운거라는 것이다. 그런데 오랜 세월 요즘 말로 하면 프로트엔드 그것도 웹이 아닌 VC++,C#으로 Native 프로그램을 주로 해오다 보니 Thread를 만들더라도 그저 UI에 Lock이 안걸리게 하는 수준 이였다. 그런데 요즘 서버에서 동작하는 서비스 프로그램을 작성하다 보니 불량 Thread를 검출해야 하는 미션이 생겼다. 그러다 보니 소위 DeadLock이 되는 상황을 만들어 놓고 Test case를 돌리려 하는..

JAVA concurrent의 번외편으로 인터럽트를 검사하는 interrupted, isInterrupt 두 함수에 대해서 간략히 다루고자 한다. 살짝 불만부터 늘어 놓자. 도대체 왜 헷갈리게 이름이 비슷한 함수를 정적 함수와 인스턴스 함수 두 개로 분리해서 제공하는지? 이렇게 불만을 늘어 놓은 계기를 마련해준 두 함수의 차이점에 대해 알아보자. thread control 편에서 interrupt()와 InterruptedException 그리고 isInterrupt() 함수에 대해서 다루었다. 아차 그런데 빼 놓은 것이 생각이 났다 Thread Class에 정적으로 구현되어 있는 interrupted() 함수이다. 현재 thread의 interrupt상태를 검사하는 함수라는 측면에서는 같은 작용을 하는..

프롤로그 JAVA7 이전 기준으로 동시성 제어(스레드 안정성)를 위해 Lock을 설정하는 방법은 소위 Monitor Lock이라고 하는 synchronized 블럭을 사용하는 방법과 재 진입성이 보장되는 명시적인 Lock인 ReentrantLock과 Reentrant-ReadWriteLock을 이용하여 Lock을 구현 하였다. 필자가 ReentrantReadWriteLock을 처음 봤을때 아 이쯤이면 뭐 됐지 Lock을 안걸고 Lock Free로 구현하면 되지 이 이상 뭐가 필요할까 했는데 JAVA8 부터 지원한는 StampedLock이 이라는 것이 아닌가? "그래 새로운것을 계속 무시하면 난 아직도 dos에서 GW-BASIC으로 개발하고 있을꺼야! 이제 이 놈이 뭔지 들춰봐야 할 때가 되었어...." ..

프롤로그 가시성과 원자성을 이해 해야 문제없는 Thead 프로그램을 작성할 가능성이 높다. Thread 프로그램을 한다는 것은 나 혼자 목공소를 운영하다가 조수라도 한명 더 들어와 그의 작업까지 내가 정의 해야하고 서로 업무에 방해가 되지 않도록 동선을 고려하여 업무를 분장해야 하는 상황과 비유 할 수 있다. 그러기 위해서 적절한 시기와 방법으로 Thread는 생성되어야 하고 쉬어야(WAIT) 하며 때로는 멈춰야(BLOCK) 한다. 그리고 (제일 중요)완벽하게 Task를 완수 해야 한다. 필자는 이런 일련의 Thread 운영을 Thread Control이라 부르기로 했다. 그리고 이번 편에서는 소위 Thread Pool을 이용한 Thread Control 이 아닌 전통적인 방법으로 Thread를 생성하고..

프롤로그 전편에서 다루었던 가시성과 이번에 다루려고 하는 원자성라는 주제가 Muti-Thread 상황에서 Thread간 공유 메모리 이슈를 발생시킨 다는 점에서 공통분모를 가지고 있고 서로간의 상호작용을 잘 염두해 두어야 한다는 것은 사실이다. 그렇지만 시스템 관점에서 보면 이 두 개념은 조금 다른곳에 존재한다. 가시성은 CPU - Cache - Memory관계상의 개념이고 원자성은 한줄의 프로그램 statement가 컴파일러에 기계어로 변경되며 이를 기계가 순차적으로 처리하기 위한 여러개의 machine instruction이 만들어져 실행되기 때문에 일어나는 현상을 설명하는 용어이기도 하다. 원자단위의 연산의 이해 원자성 즉 연산의 원자단위를 이해하기 위해 이전 편에서도 다루었던 i++를 원자연산으로..

프롤로그 가시성과 원자성 이 두가지를 이해 하면 Multi-thread프로로그램을 작성할 때 무엇을 주의해하는지 명확해진다. 또 다른 표현으로 설명 하자면 단일 Thread 프로그램에서는 가시성과 원자성을 괘념치 않아도 프로그램 작성하는데 문제가 없다. 그렇다고 해서 가시성과 원자성이 Multi-thread를 할 때만 뚜둥 나타나는 개념은 아니라는점 명확히 밝혀둔다. 하드웨어를 설계한 사람들에 의해 만들어진 원래 컴퓨터 내의 구조에 관한 이야기다. 이번 편에서는 지난편에서 설명한 이 두 가지 개념중에 가시성을 좀더 깊게 파고들어보려 한다. 비 가시성(가시성 이슈) 다른 자료나 책을 통해 가시성에 대한 개념을 이해하고 있는 독자라면 필자가 외 비 가시성이라는 반대가 되는 단어를 만들어 썼는지 감이 왔을것이..