Synchronization - 편집 역사

Pinkgo: /* Using Threads for Parallelism */

2025-06-06T07:05:22Z

Using Threads for Parallelism

Pinkgo: /* A Concurrent Server Based on Prethreading */

2025-06-06T07:05:00Z

A Concurrent Server Based on Prethreading

@@ 170번째 줄: / 170번째 줄: @@
 ==[[Semaphore]]==
 자세한 내용은 [[Semaphore]] 문서를 참조해 주십시오.
 ==Using Threads for Parallelism==

Pinkgo: /* Characterizing the Performance of Parallel Programs */

2025-06-06T07:00:30Z

Characterizing the Performance of Parallel Programs

← 이전 판		2025년 6월 6일 (금) 07:00 판
370번째 줄:		370번째 줄:

	===Characterizing the Performance of Parallel Programs===		===Characterizing the Performance of Parallel Programs===
	Figure 8은 psum-local 프로그램의 총 실행 시간을 스레드 수에 따라 나타낸 것이다. 각 경우에서 프로그램은 n = 2<sup>31</sup>이며, 4코어 환경에서 작동한다. 해당 figure에서 스레드의 숫자가 증가할 수록 실행시간이 감소하지만, ~~4개 이상으로~~ 스레드의 숫자가 증가할 ~~경우에는~~ 오히려 실행 시간이 증가하기도 한다. 이상적인 경우, 실행 시간은 스레드 수가 증가함에 따라 선형적으로 감소한다. 즉, 스레드 수가 두 배가 되면 실행 시간은 절반이 되는 것이다. 하지만 실제로는 스레드의 수가 임계치(해당 예시에서는 4개)를 초과하면, 각 코어가 여러 스레드를 컨텍스트 스위칭하며 실행해야 하므로 실행 시간이 오히려 증가하는 것이다. 따라서 parallel 프로그램은 일반적으로 CPU의 각 코어가 하나의 스레드를 실행하도록 작성된다.		[[파일:Performance of psum-local-array.png\|섬네일\|Figure 8. Performance of psum-local/array]]
			Figure 8은 psum-array, psum-local 프로그램의 총 실행 시간을 스레드 수에 따라 나타낸 것이다. 각 경우에서 프로그램은 n = 2<sup>31</sup>이며, 4코어 환경에서 작동한다. 해당 figure에서 스레드의 숫자가 증가할 수록 실행시간이 감소하지만, psum-array 프로그램의 경우에는 스레드의 숫자가 증가할 경우에 오히려 실행 시간이 증가하기도 한다. 이상적인 경우, 실행 시간은 스레드 수가 증가함에 따라 선형적으로 감소한다. 즉, 스레드 수가 두 배가 되면 실행 시간은 절반이 되는 것이다. 하지만 실제로는 스레드의 수가 임계치(해당 예시에서는 4개)를 초과하면, 각 코어가 여러 스레드를 컨텍스트 스위칭하며 실행해야 하므로 실행 시간이 오히려 증가하는 것이다. 따라서 parallel 프로그램은 일반적으로 CPU의 각 코어가 하나의 스레드를 실행하도록 작성된다.

	절대적인 실행 시간이 어떤 프로그램의 성능을 측정하는 직관적이고 궁극적인 지표이지만, parallel 프로그램이 parallelism을 얼마나 잘 활용하는지를 보여주는 지표도 존재하며, 이를 parallel 프로그램의 속도 향상도(speedup)라고 한다. 이때 속도 향상도를 보는 첫 번째 관점은 strong scailing이다. strong scailing은 작업의 총량을 고정한 채로, pararell 처리에 사용할 프로세서(스레드) 수를 늘려가며 실행 시간을 줄이는 방식을 의미한다. 이러한 관점에서 속도 향상도는 아래와 같이 정의된다.		절대적인 실행 시간이 어떤 프로그램의 성능을 측정하는 직관적이고 궁극적인 지표이지만, parallel 프로그램이 parallelism을 얼마나 잘 활용하는지를 보여주는 지표도 존재하며, 이를 parallel 프로그램의 속도 향상도(speedup)라고 한다. 이때 속도 향상도를 보는 첫 번째 관점은 strong scailing이다. strong scailing은 작업의 총량을 고정한 채로, pararell 처리에 사용할 프로세서(스레드) 수를 늘려가며 실행 시간을 줄이는 방식을 의미한다. 이러한 관점에서 속도 향상도는 아래와 같이 정의된다.
379번째 줄:		380번째 줄:
	이때 절대 속도 향상도가 parallelism의 효과를 더욱 정확히 측정할 수 있는 지표이다. 왜냐하면 parallel 프로그램은 1개의 프로세서에서 실행할 때에도 동기화에 의한 오버헤드가 존재하며, 이는 상대 속도 향상도의 분자(<math>T_1</math>)를 인위적으로 키워서 수치를 잘못 해석할 수 있기 때문이다. 하지만 상대 속도 향상도는 굳이 해당 프로그램에 대한 sequential한 버전을 따로 만들 필요가 없으므로 더욱 간편하다는 장점이 있다. 이와 관련된 지표로 효율성(efficiency)가 있으며, 이는 아래와 같이 계산된다:		이때 절대 속도 향상도가 parallelism의 효과를 더욱 정확히 측정할 수 있는 지표이다. 왜냐하면 parallel 프로그램은 1개의 프로세서에서 실행할 때에도 동기화에 의한 오버헤드가 존재하며, 이는 상대 속도 향상도의 분자(<math>T_1</math>)를 인위적으로 키워서 수치를 잘못 해석할 수 있기 때문이다. 하지만 상대 속도 향상도는 굳이 해당 프로그램에 대한 sequential한 버전을 따로 만들 필요가 없으므로 더욱 간편하다는 장점이 있다. 이와 관련된 지표로 효율성(efficiency)가 있으며, 이는 아래와 같이 계산된다:
	* <math>E_p = \frac{S_p}{p} = \frac{T_1}{pT_p}</math>		* <math>E_p = \frac{S_p}{p} = \frac{T_1}{pT_p}</math>
	이는 보통 0~100% 사이의 백분율로 표현되며, parallelism으로 인한 오버헤드를 측정한다. <math>E_p</math>가 100%에 가까울 수록 오버헤드가 적다는 것을 의미한다.		[[파일:Performance of psum-local.png\|섬네일\|Figure 9. Performance of psum-local]]
			이는 보통 0~100% 사이의 백분율로 표현되며, parallelism으로 인한 오버헤드를 측정한다. <math>E_p</math>가 100%에 가까울 수록 오버헤드가 적다는 것을 의미한다. Figure 9은 psum-local 프로그램에 대한 퍼포먼스를 나타낸 표이다. 해당 표를 분석하면 효율성이 그럭저럭 괜찮은 것을 볼 수 있다. 하지만 실제 코드를 구현할 경우에는 동기화가 더욱 복잡해지기 때문에 효율성을 높이는 것이 더욱 어려워진다.

	속도 향상도를 보는 다른 관점은 weak scailing이다. 이는 프로세서의 수를 늘릴 때 문제의 크기도 함께 늘려서, 각 프로세서가 처리하는 작업량이 일정하도록 하는 방식이다. 이 경우 속도 향상도와 효율성은 단위 시간당 수행된 총 작업량을 기준으로 측정된다. 예를 들어, 프로세서 수를 2배로 늘리고 처리하는 작업량도 2배로 늘렸을 때, 한 시간당 처리량이 두 배가 되면 선형적인 속도 향상도와 100% 효율을 얻는 것이다.		속도 향상도를 보는 다른 관점은 weak scailing이다. 이는 프로세서의 수를 늘릴 때 문제의 크기도 함께 늘려서, 각 프로세서가 처리하는 작업량이 일정하도록 하는 방식이다. 이 경우 속도 향상도와 효율성은 단위 시간당 수행된 총 작업량을 기준으로 측정된다. 예를 들어, 프로세서 수를 2배로 늘리고 처리하는 작업량도 2배로 늘렸을 때, 한 시간당 처리량이 두 배가 되면 선형적인 속도 향상도와 100% 효율을 얻는 것이다.
392번째 줄:		394번째 줄:

	</syntaxhighlight>		</syntaxhighlight>


	==각주==		==각주==
	[[분류:컴퓨터 시스템]]		[[분류:컴퓨터 시스템]]

Pinkgo: /* Characterizing the Performance of Parallel Programs */

2025-06-06T06:52:18Z

Characterizing the Performance of Parallel Programs

← 이전 판		2025년 6월 6일 (금) 06:52 판
370번째 줄:		370번째 줄:

	===Characterizing the Performance of Parallel Programs===		===Characterizing the Performance of Parallel Programs===
			Figure 8은 psum-local 프로그램의 총 실행 시간을 스레드 수에 따라 나타낸 것이다. 각 경우에서 프로그램은 n = 2<sup>31</sup>이며, 4코어 환경에서 작동한다. 해당 figure에서 스레드의 숫자가 증가할 수록 실행시간이 감소하지만, 4개 이상으로 스레드의 숫자가 증가할 경우에는 오히려 실행 시간이 증가하기도 한다. 이상적인 경우, 실행 시간은 스레드 수가 증가함에 따라 선형적으로 감소한다. 즉, 스레드 수가 두 배가 되면 실행 시간은 절반이 되는 것이다. 하지만 실제로는 스레드의 수가 임계치(해당 예시에서는 4개)를 초과하면, 각 코어가 여러 스레드를 컨텍스트 스위칭하며 실행해야 하므로 실행 시간이 오히려 증가하는 것이다. 따라서 parallel 프로그램은 일반적으로 CPU의 각 코어가 하나의 스레드를 실행하도록 작성된다.

			절대적인 실행 시간이 어떤 프로그램의 성능을 측정하는 직관적이고 궁극적인 지표이지만, parallel 프로그램이 parallelism을 얼마나 잘 활용하는지를 보여주는 지표도 존재하며, 이를 parallel 프로그램의 속도 향상도(speedup)라고 한다. 이때 속도 향상도를 보는 첫 번째 관점은 strong scailing이다. strong scailing은 작업의 총량을 고정한 채로, pararell 처리에 사용할 프로세서(스레드) 수를 늘려가며 실행 시간을 줄이는 방식을 의미한다. 이러한 관점에서 속도 향상도는 아래와 같이 정의된다.
			<math>S_p=\frac{T_1}{T_p}</math>
			이때 <math>p</math>는 코어의 수, <math>T_k</math>는 k개가 있을 때의 실행 시간이다. 이때 <math>S_p</math>는 아래와 같이 갈린다:
			* <math>S_p</math>가 절대 속도 향상도(absolute speedup): <math>T_1</math>이 sequential 프로그램의 실행 시간일 때
			* <math>S_p</math>가 상대 속도 향상도(absolute speedup): <math>T_1</math>이 parallel 프로그램의 실행 시간일 때
			이때 절대 속도 향상도가 parallelism의 효과를 더욱 정확히 측정할 수 있는 지표이다. 왜냐하면 parallel 프로그램은 1개의 프로세서에서 실행할 때에도 동기화에 의한 오버헤드가 존재하며, 이는 상대 속도 향상도의 분자(<math>T_1</math>)를 인위적으로 키워서 수치를 잘못 해석할 수 있기 때문이다. 하지만 상대 속도 향상도는 굳이 해당 프로그램에 대한 sequential한 버전을 따로 만들 필요가 없으므로 더욱 간편하다는 장점이 있다. 이와 관련된 지표로 효율성(efficiency)가 있으며, 이는 아래와 같이 계산된다:
			* <math>E_p = \frac{S_p}{p} = \frac{T_1}{pT_p}</math>
			이는 보통 0~100% 사이의 백분율로 표현되며, parallelism으로 인한 오버헤드를 측정한다. <math>E_p</math>가 100%에 가까울 수록 오버헤드가 적다는 것을 의미한다.

			속도 향상도를 보는 다른 관점은 weak scailing이다. 이는 프로세서의 수를 늘릴 때 문제의 크기도 함께 늘려서, 각 프로세서가 처리하는 작업량이 일정하도록 하는 방식이다. 이 경우 속도 향상도와 효율성은 단위 시간당 수행된 총 작업량을 기준으로 측정된다. 예를 들어, 프로세서 수를 2배로 늘리고 처리하는 작업량도 2배로 늘렸을 때, 한 시간당 처리량이 두 배가 되면 선형적인 속도 향상도와 100% 효율을 얻는 것이다.

	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">

Pinkgo: /* A Concurrent Server Based on Prethreading */

2025-06-06T06:17:49Z

A Concurrent Server Based on Prethreading

← 이전 판		2025년 6월 6일 (금) 06:17 판
223번째 줄:		223번째 줄:
	}		}
	</syntaxhighlight>		</syntaxhighlight>
	위 코드에서 concurrent 서버는 새로운 클라이언트가 접속할 때마다 새로운 스레드를 생성한다. Concurrent Server 문서에 다룬 [[Concurrent Programming#A Concurrent Server Based on Threads\|스레드 기반의 서버]]의 단점은 클라이언트마다 새 스레드를 만드는데 적지 않은 비용이 발생한다는 것이다. 하지만 위에서 제시된 prethreading 방식을 이용한 서버는 이러한 문제를 해결하기 위해서 figure 6에 제시된 생산자-소비자(Producer-Consumer) 모델을 사용하여 이러한 오버헤드를 줄이고자 한다. ~~이를 위해~~ 이러한 서버는 메인 스레드(main thread)와 작업 스레드(worker thread)로 구성된다. 메인 스레드는 반복적으로 클라이언트로부터의 연결 요청을 수락하고, 그로부터 생성된 connfd를 버퍼(sbuf)에 저장한다. 각 작업 스레드는 반복적으로 버퍼에서 디스크립터를 꺼내어서 클라이언트 서비스를 수행한 다음, 다음 connfd를 기다린다. 이는 위 코드에서 제시되었듯이, 아래와 같은 control flow를 가진다:		[[파일:Organization of a prethreaded concurrent server.png\|섬네일\|Figure 6. Organization of a prethreaded concurrent server]]
			위 코드에서 concurrent 서버는 새로운 클라이언트가 접속할 때마다 새로운 스레드를 생성한다. Concurrent Server 문서에 다룬 [[Concurrent Programming#A Concurrent Server Based on Threads\|스레드 기반의 서버]]의 단점은 클라이언트마다 새 스레드를 만드는데 적지 않은 비용이 발생한다는 것이다. 하지만 위에서 제시된 prethreading 방식을 이용한 서버는 이러한 문제를 해결하기 위해서 figure 6에 제시된 생산자-소비자(Producer-Consumer) 모델을 사용하여 이러한 오버헤드를 줄이고자 한다. 이러한 모델에서 서버는 메인 스레드(main thread)와 작업 스레드(worker thread)로 구성된다. 메인 스레드는 반복적으로 클라이언트로부터의 연결 요청을 수락하고, 그로부터 생성된 connfd를 버퍼(sbuf)에 저장한다. 각 작업 스레드는 반복적으로 버퍼에서 디스크립터를 꺼내어서 클라이언트 서비스를 수행한 다음, 다음 connfd를 기다린다. 이는 위 코드에서 제시되었듯이, 아래와 같은 control flow를 가진다:
	* 메인 스레드의 경우		* 메인 스레드의 경우
	*# 버퍼 sbuf를 초기화 한 후, 작업 스레드 집합을 생성한다.		*# 버퍼 sbuf를 초기화 한 후, 작업 스레드 집합을 생성한다.
267번째 줄:		268번째 줄:

	==Using Threads for Parallelism==		==Using Threads for Parallelism==
			[[파일:Relationships between the sets of programs.png\|섬네일\|Figure 7. Relationships between the sets of programs]]
	요즘 나오는 컴퓨터들은 figure 6와 같은 멀티코어 프로세서를 가지고 있으며, 이는 concurrent programming을 더욱 빠르게 실행한다. 이는 OS 커널이 스레드들을 단일 코어에서 순차적으로 실행하는 대신, 멀티코어에서 병렬적으로 스케쥴링하여 처리하기 때문이다. 이러한 병렬성(parallelism)을 활용하는 것은 매우 중요하다. Figure 7는 sequential 프로그램, concurrent 프로그램, parallel 프로그램 사이의 집합 관계로 나눌 수 있다. 모든 프로그램은 sequential 프로그램과 concurrent 프로그램이라는 서로소 집합으로 나눌 수 있다. 이때 parallel 프로그램은 concurrent 프로그램의 진부분집합이다. 아래는 parallel 프로그램의 간단한 예시이다.		요즘 나오는 컴퓨터들은 figure 6와 같은 멀티코어 프로세서를 가지고 있으며, 이는 concurrent programming을 더욱 빠르게 실행한다. 이는 OS 커널이 스레드들을 단일 코어에서 순차적으로 실행하는 대신, 멀티코어에서 병렬적으로 스케쥴링하여 처리하기 때문이다. 이러한 병렬성(parallelism)을 활용하는 것은 매우 중요하다. Figure 7는 sequential 프로그램, concurrent 프로그램, parallel 프로그램 사이의 집합 관계로 나눌 수 있다. 모든 프로그램은 sequential 프로그램과 concurrent 프로그램이라는 서로소 집합으로 나눌 수 있다. 이때 parallel 프로그램은 concurrent 프로그램의 진부분집합이다. 아래는 parallel 프로그램의 간단한 예시이다.
	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">

Pinkgo: /* Using Threads for Parallelism */

2025-06-06T05:37:38Z

Using Threads for Parallelism

@@ 327번째 줄: / 327번째 줄: @@
+}
 </syntaxhighlight>
-예를 들어 정수 0부터 n-1까지의 합을 병렬로 계산하는 상황을 생각하자. 가장 단순한 해결책은 스레드들이 mutex로 보호되는 공유 전역 변수에 합을 더하도록 하는 것이다. 이때 단순화를 위해 t개의 서로 다른 스레드들이 존재한다고 가정할 때, 0 ~ n까지의 각 구간은 n/t개의 원소를 가진다. 따라서 이를 구현하기 위해서는 <code>sum_mutex</code>를 통해서 스레드를 호출할 때 myid를 통해서 스레드에게 주어진 각 구간의 합을 공유 전역 변수에 더하도록 하면 된다. 이렇게 구현된 프로그램은 싱글 스레드로 실행할 때에도 매우 느릴 뿐 아니라, 여러 스레드로 병렬 실행할 경우 오히려 더욱 느려진다는 놀라운 결과를 보여준다. 사실 이는 당연한 결과이기도 하다. 왜냐하면 하나의 프로세스 내의 반복문 내에서 실행될 수 있었던 프로그램을, 더 많은 스레드를
+예를 들어 정수 0부터 n-1까지의 합을 병렬로 계산하는 상황을 생각하자. 가장 단순한 해결책은 스레드들이 mutex로 보호되는 공유 전역 변수에 합을 더하도록 하는 것이다. 이때 단순화를 위해 t개의 서로 다른 스레드들이 존재한다고 가정할 때, 0 ~ n까지의 각 구간은 n/t개의 원소를 가진다. 따라서 이를 구현하기 위해서는 <code>sum_mutex</code>를 통해서 스레드를 호출할 때 myid를 통해서 스레드에게 주어진 각 구간의 합을 공유 전역 변수에 더하도록 하면 된다. 이렇게 구현된 프로그램은 싱글 스레드로 실행할 때에도 매우 느릴 뿐 아니라, 여러 스레드로 병렬 실행할 경우 오히려 더욱 느려진다는 놀라운 결과를 보여준다. 사실 이는 당연한 결과이기도 하다. 왜냐하면 하나의 프로세스 내의 반복문 내에서 실행될 수 있었던 프로그램을, 더 많은 스레드를 이용하여 구현하는 것이며, 스레드가 많아질 수록 동기화 연산(P, V)<ref>동기화 연산(P, V)은 단일 메모리 업데이트에 비해 매우 비싸다.</ref>이 더욱 많이 사용되기 때문이다. 이는 아래와 같은 결론을 제시한다:
 <syntaxhighlight lang="c">

Pinkgo: /* Using Threads for Parallelism */

2025-06-06T03:06:32Z

Using Threads for Parallelism

@@ 267번째 줄: / 267번째 줄: @@
 ==Using Threads for Parallelism==
 요즘 나오는 컴퓨터들은 figure 6와 같은 멀티코어 프로세서를 가지고 있으며, 이는 concurrent programming을 더욱 빠르게 실행한다. 이는 OS 커널이 스레드들을 단일 코어에서 순차적으로 실행하는 대신, 멀티코어에서 병렬적으로 스케쥴링하여 처리하기 때문이다. 이러한 병렬성(parallelism)을 활용하는 것은 매우 중요하다. Figure 7는 sequential 프로그램, concurrent 프로그램, parallel 프로그램 사이의 집합 관계로 나눌 수 있다. 모든 프로그램은 sequential 프로그램과 concurrent 프로그램이라는 서로소 집합으로 나눌 수 있다. 이때 parallel 프로그램은 concurrent 프로그램의 진부분집합이다. 아래는 parallel 프로그램의 간단한 예시이다.
 ==각주==
 [[분류:컴퓨터 시스템]]

Pinkgo: /* 각주 */

2025-06-06T02:36:34Z

각주

← 이전 판		2025년 6월 6일 (금) 02:36 판
265번째 줄:		265번째 줄:
	</syntaxhighlight>		</syntaxhighlight>
	위에서 다룬 <code>echo_cnt()</code> 함수는 <code>echo()</code> 함수의 변형으로, 모든 클라이언트로부터 수신된 누적 바이트 수를 byte_cnt라는 전역 변수에 저장한다. 이 경우, 해당 함수를 구현하기 위해서는 byte_cnt 카운터(counter) 변수와 mutex 세마포어를 초기화하여야 한다. 하나의 접근 방식은 메인 스레드가 명시적으로 초기화 함수를 호출하는 것이다. 다른 접근 방식은 해당 코드에서의 구현과 같이 <code>pthread_once()</code> 함수를 사용하여, 어떤 스레드가 처음으로 <code>echo_cnt()</code> 함수를 호출할 때 초기화 함수가 호출되도록 하는 것이다.		위에서 다룬 <code>echo_cnt()</code> 함수는 <code>echo()</code> 함수의 변형으로, 모든 클라이언트로부터 수신된 누적 바이트 수를 byte_cnt라는 전역 변수에 저장한다. 이 경우, 해당 함수를 구현하기 위해서는 byte_cnt 카운터(counter) 변수와 mutex 세마포어를 초기화하여야 한다. 하나의 접근 방식은 메인 스레드가 명시적으로 초기화 함수를 호출하는 것이다. 다른 접근 방식은 해당 코드에서의 구현과 같이 <code>pthread_once()</code> 함수를 사용하여, 어떤 스레드가 처음으로 <code>echo_cnt()</code> 함수를 호출할 때 초기화 함수가 호출되도록 하는 것이다.

			==Using Threads for Parallelism==
			요즘 나오는 컴퓨터들은 figure 6와 같은 멀티코어 프로세서를 가지고 있으며, 이는 concurrent programming을 더욱 빠르게 실행한다. 이는 OS 커널이 스레드들을 단일 코어에서 순차적으로 실행하는 대신, 멀티코어에서 병렬적으로 스케쥴링하여 처리하기 때문이다. 이러한 병렬성(parallelism)을 활용하는 것은 매우 중요하다. Figure 7는 sequential 프로그램, concurrent 프로그램, parallel 프로그램 사이의 집합 관계로 나눌 수 있다. 모든 프로그램은 sequential 프로그램과 concurrent 프로그램이라는 서로소 집합으로 나눌 수 있다. 이때 parallel 프로그램은 concurrent 프로그램의 진부분집합이다. 아래는 parallel 프로그램의 간단한 예시이다.


	==각주==		==각주==
	[[분류:컴퓨터 시스템]]		[[분류:컴퓨터 시스템]]

Pinkgo: /* A Concurrent Server Based on Prethreading */

2025-06-05T17:48:52Z

A Concurrent Server Based on Prethreading

← 이전 판		2025년 6월 5일 (목) 17:48 판
234번째 줄:		234번째 줄:
	#include "csapp.h"		#include "csapp.h"

	static int byte_cnt; /~~* Byte counter *~~/		static int byte_cnt; //서버가 지금까지 읽은 모든 바이트의 누적 합.
	static sem_t mutex; /~~* and the mutex that protects it *~~/		static sem_t mutex; //byte_cnt를 여러 스레드가 동시에 접근하지 못하게 하는 세마포어

	static void init_echo_cnt(void)		static void init_echo_cnt(void) //서버 실행 중 단 한 번만 호출되도록 보장된다.
	{		{
	Sem_init(&mutex, 0, 1);		Sem_init(&mutex, 0, 1); //세마포어 mutex를 1로 초기화하여 사용한다.
	byte_cnt = 0;		byte_cnt = 0;
	}		}

			//클라이언트 소켓(connfd)을 통해 라인 단위로 문자열을 echo한다. 동시에 총 수신 바이트 수(byte_cnt)를 세고 출력한다.
	void echo_cnt(int connfd)		void echo_cnt(int connfd)
	{		{
	int n;		int n;
	char buf[MAXLINE];		char buf[MAXLINE];
	rio_t rio;		rio_t rio;
	~~static pthread_once_t once = PTHREAD_ONCE_INIT~~;

	Pthread_once(&once, init_echo_cnt);		//init_echo_cnt()를 스레드 환경에서 한 번만 호출하도록 보장하는 구문
	Rio_readinitb(&rio, connfd);		static pthread_once_t once = PTHREAD_ONCE_INIT
	while((n = Rio_readlineb(&rio, buf, MAXLINE)) != 0) {		Pthread_once(&once, init_echo_cnt);
	P(&mutex);
	byte_cnt += n;		Rio_readinitb(&rio, connfd); //connfd를 통한 연결을 위해서 rio 버퍼를 초기화한다.
	printf("server received %d (%d total) bytes on fd %d\n",		while((n = Rio_readlineb(&rio, buf, MAXLINE)) != 0) { //클라이언트가 데이터를 보내는 동안 계속 읽음
	n, byte_cnt, connfd);		P(&mutex); //mutex 세마포어를 통해서 byte_cnt를 보호
	V(&mutex);		byte_cnt += n; //n은 이번에 읽은 바이트 수, 이를 byte_cnt에 추가
	Rio_writen(connfd, buf, n);		printf("server received %d (%d total) bytes on fd %d\n", n, byte_cnt, connfd);
			V(&mutex); //보호 해제
			Rio_writen(connfd, buf, n); //이번 루프에서 읽어 들인 문자열을 출력
	}		}
	}		}
	</syntaxhighlight>		</syntaxhighlight>
			위에서 다룬 <code>echo_cnt()</code> 함수는 <code>echo()</code> 함수의 변형으로, 모든 클라이언트로부터 수신된 누적 바이트 수를 byte_cnt라는 전역 변수에 저장한다. 이 경우, 해당 함수를 구현하기 위해서는 byte_cnt 카운터(counter) 변수와 mutex 세마포어를 초기화하여야 한다. 하나의 접근 방식은 메인 스레드가 명시적으로 초기화 함수를 호출하는 것이다. 다른 접근 방식은 해당 코드에서의 구현과 같이 <code>pthread_once()</code> 함수를 사용하여, 어떤 스레드가 처음으로 <code>echo_cnt()</code> 함수를 호출할 때 초기화 함수가 호출되도록 하는 것이다.
	<~~syntaxhighlight lang="c"~~>

	</~~syntaxhighlight~~>

	<~~syntaxhighlight lang="c"~~>

	</~~syntaxhighlight~~>

	==각주==		==각주==
	[[분류:컴퓨터 시스템]]		[[분류:컴퓨터 시스템]]

Pinkgo: /* A Concurrent Server Based on Prethreading */

2025-06-05T17:34:37Z

A Concurrent Server Based on Prethreading

@@ 204번째 줄: / 204번째 줄: @@
      while (1) {
          clientlen = sizeof(struct sockaddr_storage);
-         connfd = Accept(listenfd, (SA*) &clientaddr, &clientlen); //클라이언트 요청이 오면 Accept()로 연결을 수락.
-         sbuf_insert(&sbuf, connfd);                               //수락한 결과 얻은 connfd를 sbuf에 등록하기 -> 나중에 스레드에서 처리
+        //클라이언트 요청이 오면 Accept()로 연결을 수락.
+     }
+}
@@ 219번째 줄: / 223번째 줄: @@
+}
 </syntaxhighlight>
-위 코드에서 concurrent 서버는 새로운 클라이언트가 접속할 때마다 새로운 스레드를 생성한다.  Concurrent Server 문서에 다룬 [[Concurrent Programming#A Concurrent Server Based on Threads|스레드 기반의 서버]]의  단점은 클라이언트마다 새 스레드를 만드는데 적지 않은 비용이 ㅂ잘생한다는 것이다. 이 서버는 메인 스레드(main thread)와 작업 스레드(worker thread)로 구성된다. 메인 스레드는 반복적으로 클라이언트로부터의 연결 요청을 수락하고,
+위 코드에서 concurrent 서버는 새로운 클라이언트가 접속할 때마다 새로운 스레드를 생성한다.  Concurrent Server 문서에 다룬 [[Concurrent Programming#A Concurrent Server Based on Threads|스레드 기반의 서버]]의  단점은 클라이언트마다 새 스레드를 만드는데 적지 않은 비용이 발생한다는 것이다. 하지만 위에서 제시된 prethreading 방식을 이용한 서버는 이러한 문제를 해결하기 위해서 figure 6에 제시된 생산자-소비자(Producer-Consumer) 모델을 사용하여 이러한 오버헤드를 줄이고자 한다. 이를 위해 이러한 서버는 메인 스레드(main thread)와 작업 스레드(worker thread)로 구성된다. 메인 스레드는 반복적으로 클라이언트로부터의 연결 요청을 수락하고, 그로부터 생성된 connfd를 버퍼(sbuf)에 저장한다. 각 작업 스레드는 반복적으로 버퍼에서 디스크립터를 꺼내어서 클라이언트 서비스를 수행한 다음, 다음 connfd를 기다린다. 이는 위 코드에서 제시되었듯이, 아래와 같은 control flow를 가진다:
 <syntaxhighlight lang="c">
@@ 227번째 줄: / 267번째 줄: @@
 </syntaxhighlight>
 ==각주==
 [[분류:컴퓨터 시스템]]