표준 C나 C++로 비동기함수를 자체적으로 만들 수 있을까요? Microsoft사의 CreateThread로 비동기함수(정확하게 비동기인지는 확신이 안 서지만요)를 만들지만 CreateThread 부류를 사용하지 않고 비동기함수를 만들 수 있는지 궁금합니다. 그리고 어떻게 만드는 것인가요?
* 전화 : 동기 , 양단 간에 동시에 정보가 공유/일치되고 있음, 상대방이 다른 일을 하지 않고 항시 대기 중(전화를 받지 않는데 전화가 될리 없음)
* 편지 : 비동기, 양단 간에 동시에 정보가 공유/일치 되지는 않음. 단, 언젠가는 될 것임. 상대방은 임의의 일을 하고 있어도 됨. (편지는 받으려고 하지 않아도 우체통에 도착함, 단지, 보낸 사람입장에서 받은건지? 읽은건지? 응답은 언제할지?등을 응답전에는(동기화하기 전에는) 알 수 없음.)
** 논리적 관점 비중이 크고, 결국은, 한 시점에서, 모든 시스템에서 정보를 절대적으로 일치 시켜야 함('동기화 한다', '동기를 맞춘다'라는 표현). 트랜잭션을 예로 들 수 있음.
---------
* 블록 : 어떤 일을 마칠 때까지 대기. 예들 들어, '청소 해!'라고 하고는 청소 끝날 때 까지 청소하는 것에 몰입하며, 다른 할 일은 쳐다 보지도 않고 청소하는 것을 집중 감시/관리. busy waiting이 전형적이며, 동시에 여러 개의 일(i/o등)을 하려면 제어권이 여러 개 필요(멀티프로세스,멀티쓰레드)하여 자원 소모가 많고, 확장성(scalability)은 별로 임(CPU또는 코어가 많다지만 한계가 있으니). 로직은 간단해져서 프로그램이 쉬움(논블록 대비).
* 논블록 : 어떤 일을 수행하라는 명령만 통보하고 그 결과는 추후에 받음. 예를 들어, '청소 해! 끝나면 어디로(보통 콜백) 보고 해!' 라고 명령하고, 자신은 다른 쓸모(?) 있는 일을 하고자 할 때 사용하는 것. 다수 개의 일에 대해 시간을 쪼개서 처리하게 됨. 확장성은 비교적 좋음.
----------
운영체제가 제공하는 모든 서비스(시스템호출)는 블록,논블록으로 동작하며, 논블록으로 하는 경우, 어떤 작업에 대한 관리가 전적으로 프로그래머에게 있게 되기 때문에 로직이 블록방식에 비해 복잡해짐.
일장일단이 있으며, 보통은 짬뽕형을 많이 사용함. 이에 큐잉개념을 넣으면 보다 나아짐.
예를 들어, 동시 1만명의 고객이 접촉하는 은행인 경우, 이를 위해 1만개의 창구(쓰레드, 프로세스)를 만들면 블록방식으로 설계되었다고 할 것이고, 100명의 직원이(100개의 쓰레드나 프로세스로) 100명을 순차(논블록으로)로 응대하는 방식이면 논블록으로 설계해야 할 것입니다. 아울러, 대기 시간과 적절한 스케쥴링을 위한다면 큐잉개념(번호표등)을 섞어주면 좋을 것 같네요.
멈추지 않으면. 비동기네요.
-----------------------
비동기 == NonBlocking == 멈추지 않는다.
Asynchronous 비동기
-----------------------
리눅스
writev == 동시 전송
-----------------------
윈도우
overlapped I/O == 중첩 전송
IOCP == 완료포트
-----------------------
주워들은 함수
ioctl
fcntl
epoll
select
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
동기냐 비동기냐 블럭이냐 논블럭이냐 다른
동기냐 비동기냐
블럭이냐 논블럭이냐
다른 문제입니다. 제가 알기론
- 동기/블럭
- 동기/논블럭
- 비동기/블럭
- 비동기/논블럭
모두 가능합니다.
http://blogs.msdn.com/b/csliu/archive/2009/08/27/i-o-concept-blocking-non-blocking-vs-sync-async.aspx
에도 정리되어 있군요.
그렇죠. 동기랑 넌 블러킹(non
그렇죠.
동기랑 넌 블러킹(non blocking)은 다른 개념입니다.
block 여부는 기본적으로 I/O 요청이 끝날 때까지 대기하느냐 아니냐의 여부이고,
동기 여부는 I/O 요청이 즉각 처리되느냐 아니냐의 여부입니다.
그러니까,
I/O 요청이 즉각 처리되는 함수를 불렀으면서
직접 polling 방식으로 busy waiting 하며 I/O 요청을 기다리는 방식은 동기 + 블럭 방식,
시스템이 I/O 요청의 완료를 통지해 주는 방식은 동기 + 논 블럭 방식인 것입니다.
I/O 요청이 즉각 처리되지 않는, 가령 큐 따위에 처리할 작업을 붙이고 나오기만 하는 경우는 비동기 방식입니다.
그러니까 좋을 때 알아서 처리되는 방식인 것이죠.
이 경우에도, 흔하진 않지만 처리의 완료 시점까지 직접 기다리면 비동기 + 블럭 방식인 것이고,
처리의 완료를 시스템이 통지해 주는 대부분의 케이스에선 비동기 + 논 블럭 방식인 것입니다.
===
http://cafe.daum.net/codeinside
..
std:: async 인가를 쓰세요
createThread 이런건 옛날에 썻는데 요샌 c++에 쓰레드와 비동기, task프로그래밍이 잘되있어서
그런거 쓸려나요?
전 새로 만드는 프로그램에서는 모두 std::thread만 씁니다.
예전 DOS 시절에 비슷한 구현을 본 기억이
예전 DOS 시절에 비슷한 구현을 본 기억이 있습니다.
당연히 진짜 쓰레드는 아니고, 함수 호출을 통해서 두개의 함수를 교대로 전환시키는 방식이었는데,
void func1()
{
for(;;)
{
...
switch_thread();
...
}
}
void func2()
{
for(;;)
{
...
switch_thread();
...
}
}
이런 식으로 switch_thread() 를 호출하면 현재 함수에서 다른 함수로 스위칭이 되어 쓰레드를 흉내내는 거죠.
그런데 쓰고 보니 질문과는 좀 동떨어진 대답인듯 하네요. ^^
======== 서명 =======
주거지는 www.indidev.net 입니다.
윈도우에서도 그와 유사한 기능을 제공하고
윈도우에서도 그와 유사한 기능을 제공하고 있습니다.
파이버(fiber)를 이용하면 말씀하신 것과 동일하게 구현 가능합니다.
일부 언어, 라이브러리에서 제공하는 coroutine 개념(async / yield)은 실제로 fiber나 자체 context switching 구현으로 동작하고요.
===
http://cafe.daum.net/codeinside
* 전화 : 동기 , 양단 간에 동시에 정보가
* 전화 : 동기 , 양단 간에 동시에 정보가 공유/일치되고 있음, 상대방이 다른 일을 하지 않고 항시 대기 중(전화를 받지 않는데 전화가 될리 없음)
* 편지 : 비동기, 양단 간에 동시에 정보가 공유/일치 되지는 않음. 단, 언젠가는 될 것임. 상대방은 임의의 일을 하고 있어도 됨. (편지는 받으려고 하지 않아도 우체통에 도착함, 단지, 보낸 사람입장에서 받은건지? 읽은건지? 응답은 언제할지?등을 응답전에는(동기화하기 전에는) 알 수 없음.)
** 논리적 관점 비중이 크고, 결국은, 한 시점에서, 모든 시스템에서 정보를 절대적으로 일치 시켜야 함('동기화 한다', '동기를 맞춘다'라는 표현). 트랜잭션을 예로 들 수 있음.
---------
* 블록 : 어떤 일을 마칠 때까지 대기. 예들 들어, '청소 해!'라고 하고는 청소 끝날 때 까지 청소하는 것에 몰입하며, 다른 할 일은 쳐다 보지도 않고 청소하는 것을 집중 감시/관리. busy waiting이 전형적이며, 동시에 여러 개의 일(i/o등)을 하려면 제어권이 여러 개 필요(멀티프로세스,멀티쓰레드)하여 자원 소모가 많고, 확장성(scalability)은 별로 임(CPU또는 코어가 많다지만 한계가 있으니). 로직은 간단해져서 프로그램이 쉬움(논블록 대비).
* 논블록 : 어떤 일을 수행하라는 명령만 통보하고 그 결과는 추후에 받음. 예를 들어, '청소 해! 끝나면 어디로(보통 콜백) 보고 해!' 라고 명령하고, 자신은 다른 쓸모(?) 있는 일을 하고자 할 때 사용하는 것. 다수 개의 일에 대해 시간을 쪼개서 처리하게 됨. 확장성은 비교적 좋음.
----------
운영체제가 제공하는 모든 서비스(시스템호출)는 블록,논블록으로 동작하며, 논블록으로 하는 경우, 어떤 작업에 대한 관리가 전적으로 프로그래머에게 있게 되기 때문에 로직이 블록방식에 비해 복잡해짐.
일장일단이 있으며, 보통은 짬뽕형을 많이 사용함. 이에 큐잉개념을 넣으면 보다 나아짐.
예를 들어, 동시 1만명의 고객이 접촉하는 은행인 경우, 이를 위해 1만개의 창구(쓰레드, 프로세스)를 만들면 블록방식으로 설계되었다고 할 것이고, 100명의 직원이(100개의 쓰레드나 프로세스로) 100명을 순차(논블록으로)로 응대하는 방식이면 논블록으로 설계해야 할 것입니다. 아울러, 대기 시간과 적절한 스케쥴링을 위한다면 큐잉개념(번호표등)을 섞어주면 좋을 것 같네요.
-------
* C/C++로 만들고자 한다면, 못 만들 것이 없겠지요.
댓글 달기