일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- TCP/IP
- C#
- 에러핸들링
- 열혈 tcp/ip 프로그래밍
- inflearn
- 스프링 핵심 원리
- 10026번
- 우아한레디스
- 열혈 TCP/IP 소켓 프로그래밍
- 제프리리처
- BOJ
- Four Squares
- 2475번
- Operating System
- 이펙티브코틀린
- n타일링2
- Window-Via-c/c++
- 윤성우 저자
- HTTP
- OS
- 김영한
- 토마토
- Spring
- FIFO paging
- 우아한 테크 세미나
- C++
- 운영체제
- 스프링 입문
- redis
- Operating System.
- Today
- Total
목록분류 전체보기 (206)
나의 브을로오그으
주기억장치 관리(Main Memory Management) - 메모리 역사 * Core memory * 진공판 메모리 * 트랜지스터 메모리 * 집적회로 메모리: SRAM, DRAM - 메모리 용량 * 1970년대: 8-bit PC 64KB * 1980년대: 16-bit IBM-PC 640KB > 1MB > 4MB * 1990년대: 수MB > 수십 MB * 2000년대~: 수백 MB > 수 GB 언제나 부족한 메모리 - 프로그램 변천 * 기계어/어셈블리어 작성 * C언어 작성 * 자바, 객체지향형 언어 작성 * 숫자 처리 > 문자 처리 > 멀티미디어 처리 > Big Data - 메모리 용량 증가 vs 프로그램 크기 증가 * 언제나 부족한 메모리 - 어떻게 메모리를 효과적으로 사용할 수 있을까? * 메모리 ..
https://www.acmicpc.net/problem/9095 9095번: 1, 2, 3 더하기 각 테스트 케이스마다, n을 1, 2, 3의 합으로 나타내는 방법의 수를 출력한다. www.acmicpc.net #include #include using namespace std; int main() { ios::sync_with_stdio(false); cin.tie(NULL); int T, N, cnt = 0; int arr[11] = { 1, 1, 2 }; for (int i = 3; i > T; for (int i = 0; i > N; cout
모니터 - 모니터(Monitor) * 세마포어 이후 프로세스 동기화 도구 * 세마포어 보다 고수준 개념 - 구조 * 공유자원 + 공유자원 접근함수 * 2개의 queues; 배타동기 + 조건동기 * 공유자원 접근함수에는 최대 1개의 쓰레드만 진입 * 진입 쓰레드가 조건동기로 블록되면 새 쓰레드 진입가능 * 새 쓰레드는 조건동기로 블록된 쓰레드를 깨울 수 있다. * 깨워진 쓰레드는 현재 쓰레드가 나가면 재진입할 수 있다. - 자바의 모든 객체는 모니터가 될 수 있다. * 배타동기: synchronized 키워드 사용하여 지정 * 조건동기: wait(), notify(), notifyAll() 메소드 사용 class C { private int value, ...; synchronized void f() { ..
- 프로세스는 실행을 위해 여러 자원을 필요로 한다. * CPU, 메모리, 파일, 프린터, ...... * 어떤 자원은 갖고 있으나 다른 자원은 갖지 못할 때 (e.g .. 다른 프로세스가 사용 중) 대기해야 * 다른 프로세스 역시 다른 자원을 가지려고 대기할 때 교착상태 가능성! - 교착상태 필요조건 (Necessary Conditions) * Mutual Exclusion (상호배타) * Hold and wait (보유 및 대기) * No Preemption (비선점) * Circular wait (환형대기) 자원(Resources) - 동일 자원 * 동일 형식 (type) 자원이 여러 개 있을 수 있다. (instance) * 예: 동일 CPU 2개, 동일 프린터 3개 등 - 자원의 사용 * 요청 ..
#1. IO 멀티플렉싱 기반의 서버 멀티프로세스 서버의 단점과 대안 이전 Chapter 11(Pipe라인 기반의 서버 모델)에서는 다중접속 서버의 구현을 위해서 클라이언트의 연결요청이 있을 때 마다 새로운 프로세스를 생성하였다. 그러나 프로세스의 생성에는 꽤 많은 대가를 지불해야 하기 떄문에 많은 양의 연산과 메모리 공간도 필요하다. 또한 프로세스마다 별도의 메모리 공간을 유지하기 때문에 상호간에 데이터를 주고받으려면 다소 복잡한 방법을 택할 수밖에 없다. (IPC는 다소 복잡한 통신방식임) "그렇다면 다수의 클라이언트에게 서비스를 제공할 수 있는 (프로세스 생성 없이) 대안이 없을까??" 있다! 바로 IO 멀티플렉싱 서버가 그것이다. 물론 이 방법이 모든 문제의 해결책은 아니다. 항상 상황에 맞는 서버..
전통적 동기화 예제 - Producer and Consumer Problem * 생산자-소비자 문제 * 유한버퍼 문제 (Bounded Buffer Problem) - Readers-Writers Problem * 공유 데이터베이스 접근 - Dining Philosopher Problem * 식사하는 철학자 문제 Readers-Writers Problem - 공통 데이터베이스 * Readers : read data. never modify it. * Writers : read data and modify it * 상호배타 : 한 번에 한 개의 프로세스만 접근 - 비효율적 - 효율성 재고 * Each read or write of the shared data must happen withing a criti..
프로세스간 통신이 가능하다라는 말은? 쉽게 말하면 두 프로세스가 데이터를 주고 받을 수 있다는 말이다. 이게 되려면 두 프로세스가 동시 접근이 가능한 메모리 공간이 있어야 한다. 프로세스간 통신의 기본 이해 "내게 빵이 하나 생기면 변수 bread에 1로 변경할게. 그리고 그 빵을 먹어버리면 변수 bread의 값을 0으로 변경할게. 그리고 너는 bread값을 보고 내 상태를 파악해" 위의 말은 가장 간단한 프로세스간 규칙이라고 볼 수 있다. 즉, 프로세스 A는 말하고, 프로세스 B는 들은 셈이다. 두 프로세스가 동시에 접근 가능한 메모리 공간만 있다면, 이 공간을 통해서 얼마든지 데이터를 주고 받을 수 있다. 그런데 챕터 10의 프로세스 생성에 대한 내용 중 프로세스 생성 시 생성한 프로세스와 별개의 독..
#1. 프로세스의 이해와 활용 9단원까지 공부한 내용을 가지고 '일렬종대'의 서비스 서버를 구현하여 만들 수 있다. 단, 연결에 걸리는 시간이 클라이언트 당 1초라면, 100번째 클라이언트는 100초가 걸린다는 함정이 있다. 두 가지 유형의 서버 "첫 번째 연결요청자의 접속대기시간은 0초, 50번째 연결요청자의 접속대기시간은 50초 그리고 100번째 연결요청자의 접속대기시간은 100초! 그러나 일단 연결만 되면 1초 안에 서비스를 완료해 드립니다." -> 물론 요청 순서가 5순위 안에 든다면 서비스 만족도는 높을 것이나... 이를 넘어선다면 클라이언트는 불만이 많을 것이다. 이럴바에 밑의 내용처럼 서비스 하는것이 낫다. "모든 연결요청자의 접속대기시간은 1초를 넘기지 않습니다. 그러나 서비스를 제공받는데..
소켓의 다양한 옵션 Protocol Level Option Name Get Set SOL_SOCKET SO_SNDBUF SO_RCVBUF SO_REUSEADDR SO_KEEPALIVE SO_BROADCAST SO_DONTROUTE SO_OOBINLINE SO_ERROR SO_TYPE O O O O O O O O O O O O O O O O X X IPPROTO_IP IP_TOS IP_TTL IP_MULTICAST_TTL IP_MULTICAST_LOOP IP_MULTICAST_IF O O O O O O O O O O IPPROTO_TCP TCP_KEEPALIVE TCP_NODELAY TCP_MAXSEG O O O O O O getsockopt & setsockopt 표 09-1에서 보이듯이 거의 모든 옵션..
[Redis 운영] - 메모리 관리를 잘하자! - O(N) 관련 명령어는 주의하자! [메모리 관리를 잘하자!] - Redis는 In-Memory Data Store이기 때문에 Physical Memory이상을 사용하면 문제가 발생함. * Swap이 있으면 Swap 사용으로(Paging) 해당 메모리 Page 접근시 마다 늦어짐. (Swap이 일어난 페이지는 계속 Swap이 일어날 수 있음. 만약 원하는 Key가 Swap에 의해 Disk에 저장된 페이지라면, 데이터를 읽어올 때마다 Disk에 접근해야함. 성능이 확 떨어짐.) - Redis의 장점은 In-Memory라서 빠른건데, 디스크에 접근하게 되면 이러한 장점을 잃게됨. - 갑자기 느려진다면 이부분을 고려해봐야 함. - MaxMemory를 설정하더라도..