시뮬레이션 문제로, 나한테는 삼성 기출 중에 상당히 까다로운 문제인 것 같다 시간복잡도 계산 시, 브루트 포스로 말의 순서를 정하면 2^20 * 10번의 주사위 * 최대 5번 = 약 5천만으로 1억 안에 해결할 수 있다. map으로 다음 위치로 하나씩 움직이는 점과 모든 말의 순서를 탐색한다는 점이 시간을 오래 걸리게 했다. 계속 틀렸던 이유는 dfs가 아닌 브루트포스로 접근했는데, 말이 움직이지도 못한 채 다음 턴으로 넘어가도 이 부분에서 쌓여진 합이 답의 일부분이 되었다. 그리고 브루트포스로 하니 확실히 0.3초가 걸리는, 효율적이지 못한 시간복잡도를 보였다 문제: https://www.acmicpc.net/problem/17825 깃허브주소: https://github.com/surinoel/boj..

1. 최소 다시 빌드 기능인 /Gm을 OFF 2. 다중 프로세서 컴파일 기능인 /MP를 ON [참조] https://blankspace-dev.tistory.com/296

두 함수 모두 스레드가 종료하면 사용된 자원에 대해서 즉시 free를 한다 다만, join은 두 번째 인자인 void **형태의 반환값을 받아와서 또 다른 제어를 할 수 있다. 하지만 detach는 그런 것 없이 바로 할당된 메모리를 해제한다 그리고 join은 blocking, detach는 non-blocking 함수로, 프로세스인 메인 스레드에서 join의 사용은 뒷 코드의 내용이 바로 실행되지 않는다는 특징이 있다

pthread는 POSIX 표준 API 스레드다. 기본 glibc 라이브러리 함수가 아닌 libpthread 라이브러리에 포함되어 있으므로 컴파일 시 명시적으로 -pthread 옵션을 명시해야만 한다 스레드 반환값은 어떻게 받아서 확인할 수 있을까? join의 두번째 인자로 받아올 수 있다

프로세스가 파일을 읽는 방법에는 총 2가지가 있다 1. 파일 디스크립터 2. mmap을 통해 파일의 내용을 메모리에 매핑하여 사용 파일 디스크립터로 파일을 읽는 행위는 지양된다. 물리적인 거리에 의해서 프로세스가 디스크에서 파일을 읽는 속도는 매우 느리다. 그리고 읽는 도중에는 blocking이 되어 있으므로 CPU 효율이 떨어지게 된다 즉 OS 측면에서는 1. 시스템 콜 2. 스케쥴러 3. 인터럽트의 일을 수행하게 되고 컴퓨터구조 단에서는 1. DMA 2. System Bus 을 통해서 개선할 수 있지만 따로 추가해야 하는 부분이다 따라서 mmap의 장점은 1. 가상 메모리에 파일을 매핑하는 mmap을 사용하면 위의 일들을 줄여줄 수 있다 2. 파일의 내용을 읽을 때 제어되는 위치지정자 역시 fseek..

파일을 open할 때 두 개의 오버로딩된 함수가 존재한다. 그 중 하나는 맨 마지막에 mode_t가 붙은 하나다 int open(const char *pathname, int flags, mode_t mode) mode는 파일을 생성할 때 부여되는 권한 설정이다. 따라서 대개 0644 권한을 많이 대입한다. 반드시 O_CREAT때만 효력이 발생하고, 파일이 존재한다면 mode 권한은 재설정되지 않는다