Philosophers ⑤ 회고

4주 간의 Philosophers 구현 기간을 돌이켜 보며 쓴 글입니다.

공부 방식의 변화

배경

• 이번 프로젝트는 본과정에 들어온 이후 처음으로 그룹 스터디 방식으로 진행하였다.
• 여태까지의 과제들은 혼자서 자료를 수집하고 코드를 작성하며 해결했지만 철학자 과제는 시작한지 몇 주가 지나도 방향이 잡히지 않아서 본 스터디에 참여하게 되었다.

진행 과정

• 이번 스터디는 코드 리뷰 세미나 방식으로 각자가 자신의 방식대로 코드를 작성한 뒤에 함께 모여서 코드 리뷰와 해결책에 대해 논의를 하는 식으로 진행되었다.
• 초반에는 스터디원 모두가 과제에 대해 잘 알지 못해서 과제가 지연되었지만, 한 명, 두 명씩 개념을 이해하자 다른 스터디원에게 내용을 공유해주며 빠른 속도로 진행해나갔다.

좋았던 점

• 코드 작성 과정
  • 기존에는 내가 사용하던 자료형, 내가 알던 개념, 내가 작성하던 습관과 같이 정형화된 방식으로 과제를 해결해나갔다. 하지만 스터디원들의 코드를 리뷰하며 열거형(enum), 매크로 상수(define), memset 등의 개념들의 사용 방법을 배우고 내 코드에 적용해가며 코드 작성의 폭을 넓힐 수 있었던 것 같다.
  • 또한 서브젝트에서 놓치기 쉬운 각종 조건들을 서로에게 상기시켜줌으로써 불필요한 과정을 겪지 않을 수 있었다.
• 코드 리뷰 과정
  • 코드 리뷰를 하며 다른 스터디원들에게 내 코드의 문제를 지적받았는데, 나의 관점에서 볼 때는 생각하기 어려운 가독성의 문제, 개념 이해의 미흡, 에러의 발생 원인 등을 파악할 수 있었다.
  • 리뷰를 해주는 입장에서는 자신이 사용하지 않은 새로운 방법을 보며 관점을 넓힐 수도 있었고, 고민중이던 문제에 대한 해결책을 찾을 수도 있었다.
• 기타
  • 스터디원들의 소스코드를 하나의 Git 저장소에서 관리하기 위해 submodule의 사용법을 배우거나, 코드 리뷰를 수월하게 하기 위해 가독성과 커밋 메시지에 신경쓰는 등 협업에 필요한 다양한 능력들을 기를 수 있었다.
  • 소통에 적극적인 스터디원들 덕분에 슬랙을 통해서도 활발하게 의견을 교환하고 문제점을 함께 이야기할 수 있었다.
  • 또한 모임 시간동안 에러의 원인을 찾지 못한 경우에는 스터디원이 추가적으로 시간을 내서 지속적인 코드 리뷰를 해준 덕분에 훨씬 쉽게 원인을 파악할 수 있었다. [Git submodule] [프로젝트 초기 커밋 메시지] [프로젝트 후기 커밋 메시지]

아쉬웠던 점

• 목표 기한의 경과
  • 스터디를 시작할 때 설정한 목표 기한에서 10일가량 경과한 후에야 과제를 끝마칠 수 있었다.
  • 스터디 마지막 일주일간은 과제의 진행 속도가 굉장히 빨랐지만 초반에 과제 이해를 위해 너무 많은 시간을 쏟지 않았나 하는 생각이 든다.
  • 하지만 그만큼 과제에 대해 많은 이야기를 나누었기 때문에 이것 나름의 의미가 있었다고 생각한다.
• 공간 확보의 어려움
  • 매번 스터디를 진행할 공간을 마련하기가 어려웠다. 안그래도 적은 회의용 테이블들이 모임 시간마다 만석이라서 지하부터 2층까지를 오가며 자리를 찾는데 적잖은 시간을 썼던 것 같다.

구현 과정

좋았던 점

• 코드의 가독성과 함께 변수명, 함수명, 파일명 등을 직관적으로 짓고 기능에 맞게 나누니 디버깅이 훨씬 수월해졌다.
• 이번 과제는 특히나 에러처리에 신경을 많이 썼다. 각 과정에서 에러가 발생하면 이후에 관련된 처리를 하였는데, 이를 위해 각 함수들의 반환값, 에러가 발생할 수 있는 케이스 등에 대해 더욱 세세하게 공부할 수 있었다.
• 철학자 과제의 핵심 개념인 교착상태와 동기화, 멀티스레딩, 멀티프로세싱 등 운영체제를 공부하며 배웠던 내용들을 되짚어볼 수 있었다.

아쉬웠던 점

• 핵심 고려사항인 교착상태와 기아상태는 해결했지만 철학자가 200명 가량이 되면 얼마 못 가 죽는 문제가 발생했다.
• 또한 프로세스를 3분가량 지속해서 실행하게 되면 죽는 문제도 발생했다.
• 직접 정의한 sleep 함수인 msleep으로 딜레이를 주었을 때 딜레이의 오차가 점점 늘어나는 문제가 있었다.
  • 이 부분을 해결하기 위해 오차를 줄여주는 방식으로 msleep을 변경했지만 이 문제는 해결되지 않았다.

수정할 점

• 기존 방식 : 각 철학자들이 생성되자마자 바로 저마다의 시뮬레이션을 시작하도록 구현하였다.
• 문제점 : 철학자의 수가 충분히 많아지게 되면 마지막 철학자의 경우 자신이 굶어죽는 시간이 다 돼서야 생성되는 문제가 발생할 수 있다.
• 해결방법 : 철학자의 시뮬레이션과 초기 시간의 세팅을 모든 철학자가 생성된 이후로 설정.

과제 평가 과정

• 자원 해제의 필요성
  • 오류가 발생한 경우에는 명시적인 자원 해제가 필요하지만, 그렇지 않은 경우에는 OS에서 스스로 해제를 할 것이기 때문에 반드시 필요하지는 않다는 의견을 들었다.