프로그래밍/C/C++2010. 3. 23. 16:16
1. Reactor 패턴
다중 이벤트를 처리하기 위한 전통적인 방법중 하나로 새로운 프로세스 또는 쓰레드를 생성하여 각각의 이벤트를 처리하는 방식이 있습니다. 이는 서버가 동시에 여러 네트워크 연결을 처리해야 할 경우에 즐겨 사용되는 방법입니다. 이러한 모델이 대부분의 상황에서 잘 동작하기는 하지만, 프로세스 또는 쓰레드의 생성 및 관리와 복잡성 증가라는 단점이 있습니다.

select(), poll(), WaitForMultipleObjects()와 같은 디멀티플렉서(demultiplexer)에 기초한 Reactor 모델은 단지 하나의 프로세스 또느 쓰레드에서 여러 개의 이벤트를  처리할 수 있도록 합니다.

어떻게 이와 같은 처리가 가능할까요?

Reactor패턴은 클라이언트가 접속하면 새로운 핸들을 생성하여 관리합니다. Reactor패턴은 다수의 핸들을 일괄적으로 관리하고 운영하는 과정에서 일차적으로 멀티플렉싱을 수행하고, 주기적으로 디멀티플렉싱을 통해 새롭게 발생한 이벤트가 존재하는지 확인합니다. 만약 새로운 이벤트가 존재한다면 하나씩 가져와 Dispatch를 진행합니다.


위 그림은 Reactor패턴의 구조를 보여주고 있습니다.

Reactor는 Event Handler를 실제로 구현한 구현 클래스(Concrete Event Handler)들을 등록, 해제, 호출을 위한 인터페이스를 가지고 있습니다. Event Handler는 Reactor 패턴이 필요로 하는 추상 인터페이스들을 가지고 있어 특정 어플리케이션에 비의존적인 매커니즘을 제공합니다. 또한 Event Handler는 input, output, timer events 등 여러가지 조건에 대해 반응할 수 있도록 인터페이스를 제공합니다.

이러한 Reactor와 Event Handler의 관계는 개발자의 비지니스 로직 부분을 이벤트 핸들링과 분리를 함으로써 어떠한 Event-driven 상황이 필요한 곳이라도  Reactor패턴을 적용시킬수 있게 합니다.

다음은 이러한 Reactor패턴을 이용한 echo server의 예제입니다.


2. echo server 예제
#include <ace/OS.h>
#include <ace/Log_Msg.h>
#include <ace/Message_Block.h>
#include <ace/INET_Addr.h>
#include <ace/Svc_Handler.h>
#include <ace/SOCK_Acceptor.h>
#include <ace/SOCK_Stream.h>
#include <ace/Synch_Traits.h>
#include <ace/Reactor.h>
#include <ace/Acceptor.h>
#include <ace/Reactor_Notification_Strategy.h>

class Stream_Handler : public ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_NULL_SYNCH> {
private :
	typedef ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_NULL_SYNCH> super;
	
	ACE_INET_Addr remote_addr_;
	ACE_Reactor_Notification_Strategy noti_;

public :
	Stream_Handler()
		: noti_(0, this, ACE_Event_Handler::WRITE_MASK)
	{ /* empty */ }

	//override
	virtual int open(void * = 0)
	{
		ACE_TRACE("Stream_Handler::open");
		if( super::open() == -1 )
			return -1;
		noti_.reactor(this->reactor());
		this->msg_queue()->notification_strategy(&noti_);
		if( this->peer().get_remote_addr(remote_addr_) == 0 )
		{
			ACE_DEBUG((LM_INFO, "[DEBUG%T](%N:%l) ### New client accepted: %s:%u\n", 
				remote_addr_.get_host_addr(), remote_addr_.get_port_number()));
		}
		return 0;
	}

	//override
	virtual int handle_input(ACE_HANDLE handle = ACE_INVALID_HANDLE)
	{
		ACE_TRACE("Stream_Handler::override");
		char buf[1024];
		ssize_t recv_cnt;
		if( (recv_cnt = this->peer().recv(buf, 1024)) <= 0 )
			return -1;
		ACE_Message_Block *mb;
		ACE_NEW_RETURN(mb, ACE_Message_Block(buf, recv_cnt), -1);
		mb->wr_ptr(recv_cnt);
		this->putq(mb);
		return 0;
	}

	//override
	virtual int handle_output(ACE_HANDLE handle = ACE_INVALID_HANDLE)
	{
		ACE_TRACE("Stream_Handler::handle_output");
		ACE_Message_Block *mb;
		ACE_Time_Value nowait(ACE_OS::gettimeofday());
		while( this->getq(mb, &nowait) != -1 )
		{
			ssize_t send_cnt = this->peer().send(mb->rd_ptr(), mb->length());
			if( send_cnt == -1 )
				ACE_ERROR((LM_ERROR, "[ERROR%T](%N:%l) ### %p\n", 
                                "Stream_Handler::handle_output"));
			else
				mb->rd_ptr(send_cnt);
			if( mb->length() > 0 )
			{
				this->ungetq(mb);
				break;
			}
			mb->release();
		}
		if( this->msg_queue()->is_empty() )
			this->reactor()->cancel_wakeup(this, ACE_Event_Handler::WRITE_MASK);
		else
			this->reactor()->schedule_wakeup(this, ACE_Event_Handler::WRITE_MASK);
		return 0;
	}
	
	//override
	virtual int handle_close(ACE_HANDLE handle, ACE_Reactor_Mask close_mask)
	{
		ACE_TRACE("Stream_Handler::handle_close");
		ACE_DEBUG((LM_INFO, "[DEBUG%T](%N:%l) ### Connection close %s:%u\n", 
				remote_addr_.get_host_addr(), remote_addr_.get_port_number()));
		return super::handle_close(handle, close_mask);
	}
	
};


int ACE_TMAIN(int argc, ACE_TCHAR *argv[])
{
	ACE_INET_Addr listen;
	listen.set(9088);
	ACE_Acceptor<Stream_Handler, ACE_SOCK_ACCEPTOR> acceptor;
	acceptor.open(listen);
	ACE_Reactor::instance()->run_reactor_event_loop();
	ACE_RETURN(0);
}
Posted by devop
TAG ACE, c++, reactor

댓글을 달아 주세요

프로그래밍/C/C++2010. 3. 19. 15:54
1. ACE
ACE에 대한 개요는 다음 게시물을 참조하기 바랍니다.


2. echo server 예제 
#include <ace/OS.h>
#include <ace/Log_Msg.h>
#include <ace/Message_Block.h>
#include <ace/INET_Addr.h>
#include <ace/Proactor.h>
#include <ace/Asynch_IO.h>
#include <ace/Asynch_Acceptor.h>

class Stream_Handler : public ACE_Service_Handler {
private :
	ACE_Asynch_Read_Stream	reader_;
	ACE_Asynch_Write_Stream writer_;
	ACE_INET_Addr			remote_address_;

public :
	~Stream_Handler()
	{
		if( this->handle() != ACE_INVALID_HANDLE )
			ACE_OS::closesocket(this->handle());
	}

	//override
	virtual void open(ACE_HANDLE new_handle, ACE_Message_Block &message)
	{
		ACE_TRACE("Stream_Handler::open");
		ACE_ASSERT(new_handle != ACE_INVALID_HANDLE);
		this->handle(new_handle);
		if( reader_.open(*this) != 0 || writer_.open(*this) != 0 )
		{
			ACE_ERROR((LM_ERROR, "[ERROR%T](%N:%l) ### %p\n", "Stream_Handler::open"));
			delete this;
			return;
		}
		ACE_Message_Block *mb;
		ACE_NEW_NORETURN(mb, ACE_Message_Block(1024));
		if( reader_.read(*mb, mb->space()) != 0 )
		{
			ACE_ERROR((LM_ERROR, "[ERROR%T](%N:%l) ### %p\n", "Stream_Handler::open"));
			delete this;
			return;
		}
		ACE_DEBUG((LM_INFO, "[DEBUG%T](%N:%l) ### New client accepted: %s:%u\n", 
				remote_address_.get_host_addr(), remote_address_.get_port_number()));
	}

	//override
	virtual void addresses(const ACE_INET_Addr &remote_address, const ACE_INET_Addr &local_address)
	{
		ACE_TRACE("Stream_Handler::addresses");
		ACE_UNUSED_ARG(local_address);
		remote_address_ = remote_address;
	}
	
	//override
	virtual void handle_read_stream(const ACE_Asynch_Read_Stream::Result &result)
	{
		ACE_TRACE("Stream_Handler::handle_read_stream");
		ACE_Message_Block &mb = result.message_block();
		if( !result.success() || result.bytes_transferred() == 0 )
		{
			ACE_DEBUG((LM_INFO, "[DEBUG%T](%N:%l) ### Connection close %s:%u\n", 
				remote_address_.get_host_addr(), remote_address_.get_port_number()));
			mb.release();
			delete this;
		}
		else
		{
			if( writer_.write (mb, mb.length ()) != 0 )
			{
				ACE_ERROR((LM_ERROR, "[ERROR%T](%N:%l) ### %p\n", 
                                       "Stream_Handler::handle_read_stream"));
				mb.release();
				delete this;
			}
			else
			{
				ACE_Message_Block *new_mb;
				ACE_NEW_NORETURN(new_mb, ACE_Message_Block(1024));
				reader_.read(*new_mb, new_mb->space());
			}
		}
	}
	
	//override
	virtual void handle_write_stream(const ACE_Asynch_Write_Stream::Result &result)
	{
		ACE_TRACE("Stream_Handler::handle_write_stream");
		result.message_block().release();
	}

};


int ACE_TMAIN(int agrc, ACE_TCHAR *argv[])
{
	ACE_INET_Addr listen;
	listen.set(9088);
	ACE_Asynch_Acceptor<Stream_Handler> acceptor;
	acceptor.open(listen, 
		0,	// byte to read
		1,	// call pass_address
		ACE_DEFAULT_ASYNCH_BACKLOG,
		1,	// reuse_addr
		0,	// default proactor
		0,	// validate new connection
		1,	// reissue accept
		-1);// number of initial accepts
	ACE_Proactor::instance()->proactor_run_event_loop();
	ACE_RETURN(0);
}

3. ACE와 Boost.Asio
ACE와 Boost.Asio는 멀티플랫폼 고성능 서버를 개발하기 위한 최고의 C++ 도구입니다.
(당분간 이 둘을 뛰어넘는 라이브러리는 나오기는 힘들것 이라고 개인적으로 생각합니다.)

특히 고성능 서버 개발을 위한 비동기 작업을 운영체제의 구분에 관계없이 Proactor라는 패턴을 통해 접근할 수 있습니다.
물론 두 라이브러리 모두 Proactor를 구현할수 없는 플랫폼에 대해서는 Reactor를 통해 Proactor를 시뮬레이션해주는 기능 또한 제공합니다.


ACE와 Boost.Asio를 프로젝트에 사용하게 됨으로써 얻는 효과는 분명하지만, 이 두 라이브러리의 진입 장벽이 결코 낮지 않습니다. C++은 손바닥 뒤집듯이 자유롭게 구사할 수 있어야 하며, 디자인 패턴, 운영체제, TCP/IP 및 네트워킹에 대한 이해를 필요로 합니다. 특히 ACE의 경우 Boost.Asio보다 더욱 방대한 영역을 다루고 있기 때문에 라이브러리가 더 크고 무거우며, 그만큼 더 많은 학습량을 요구합니다.

개인적으로는 ACE를 먼저 접하고 Boost.Asio를 접하게 되었는데, Boost.Asio를 이해하는데 많은 시간이 걸리지는 않았습니다. ACE와 Boost.Asio의 예제 코드를 확인해보면 서로 유사한 형태를 지니고 있음을 확인할 수 있는데, 이는 제가 의도적으로 코드를 비슷하게 작성한 것이 아니라, 두 라이브러리 모두 Proactor라는 디자인 패턴을 통해 비동기 오퍼레이션을 처리하기 때문입니다.

ACE는 Proactor를 비롯해서 Reactor, 쓰레드, 동기화 객체, 시그널 등 운영체제의 많은 부분을 캡슐화 하고 있습니다. Boost.Asio는 쓰레드나 동기화 객체와 같은 주제를 포함하지 않지만 Boost 라이브러리 전체로 범위를 넓혀보면 ACE와 마찬가지로 쓰레드, 동기화 객체, 시그널 등을 모두 포함하고 있음을 확인할 수 있습니다. 특히 Boost는 차세대 C++ 표준이라 불리우는만큼 성능이나 버그등에 대해서는 의심의 여지가 없으며, 기존의 코드와도 쉽게 결합할수 있습니다. 

따라서, ACE와 Boost.Asio 중 선택적으로 학습을 해야하는 경우라면 Boost.Asio를 먼저 추천하겠습니다.
Posted by devop

댓글을 달아 주세요

프로그래밍/C/C++2010. 3. 19. 13:11
1. Boost.Asio
대부분의 프로그램들은 파일, 네트워크, 시리얼 케이블 또는 콘솔을 통해 외부와 소통합니다. 때론 네트워크를 사용하는 단일 입출력 작업의 완료에 많은 시간이 소모됩니다. 이러한 문제는 프로그램 개발에서 까다로운 문제입니다.

Boost.Asio는 스레드, 명시적 락킹에 기반한 동시성 모델을 사용하지 않고 이러한 긴 동작을 관리하는 도구를 제공합니다.

Boost.Asio라이브러리는 C++을 사용해 네트워크같은 운영체제의 기능을 자주 접근하는 시스템 프로그래밍을 위해 만들어졌습니다. 특히 Boost.Asio는 다음을 목표합니다.

  • 이식성 - 일반적으로 사용되는 운영체제를 지원합니다. 그리고 지원되는 운영체제에서 동일한 동작을 제공합니다.
  • 확장성 - 수천이 동시 접속 가능한 네트워크 응용프로그램 개발을 가능하게 합니다. 확장성을 위해 각각의 운영체제에서 지원하는 최적의 메커니즘을 사용해 구현합니다.
  • 효율성 - scatter-gather I/O를 지원하고, 데이터 복사를 최소화한 프로그램을 가능하게 합니다.
  • BSD 소켓같은 널리 알려진 API로부터 모델 개념화. BSD 소켓 API는 널리 구현되고 알려져 많은 문헌에서 정보를 얻을 수 있습니다. 다른 프로그래밍 언어도 종종 네트워크 API에 유사한 인터페이스를 사용합니다. Boost.Asio는 합리적으로 기존의 경험을 활용할 수 있습니다.
  • 쉬운 사용 - 새로운 사용자들에게 툴킷을 사용하여 프레임워크보다 진입 장벽을 낮춰줍니다. 기본적인 규칙과 가이드라인을 학습하는데 필요한 초기 투자를 최소화 할 수 있습니다. 그리고 라이브러리 사용자는 명시된 함수의 사용방법만 이해하면 됩니다.
  • 앞으로의 추상화를 위한 기반. 상위 수준의 추상화를 제공하는 다른 라이브러리 개발을 가능하게 합니다. 예를 들어, HTTP같은 널리 사용되는 프로토콜을 구현할 수 있습니다.

Boost.Asio는 기본적으로 네트워크에 초점을 맞추고 시작되어, 비동기 입출력 개념을 시리얼 포트, 파일등의 운영체제의 다른 자원을 포함하도록 확장되었습니다.


2. echo server 예제
#include <iostream>
#include <boost/bind.hpp>
#include <boost/asio.hpp>


class Stream_Handler {
public :
	typedef boost::asio::ip::tcp::socket Peer;

private :
	Peer peer_;
	char buf_[1024];
 
public :
	Stream_Handler(boost::asio::io_service &io_service)
		: peer_(io_service) 
	{ /* empty */ }

	void open()
	{
		peer_.async_read_some(boost::asio::buffer(buf_, 1024),
			boost::bind(&Stream_Handler::handle_read_stream, this,
				boost::asio::placeholders::error,
				boost::asio::placeholders::bytes_transferred));
	}

	void handle_read_stream(const boost::system::error_code &err, size_t byte_transferred) 
	{
		if( !err )
		{
			boost::asio::async_write(peer_, boost::asio::buffer(buf_, byte_transferred),
				boost::bind(&Stream_Handler::handle_write_stream, this, boost::asio::placeholders::error));
				
		}
		else
		{
			std::cout << "handle_read_stream: " << err << std::endl;
			delete this;
		}
	}

	void handle_write_stream(const boost::system::error_code &err)
	{
		if( !err )
		{
			peer_.async_read_some(boost::asio::buffer(buf_, 1024),
				boost::bind(&Stream_Handler::handle_read_stream, this,
					boost::asio::placeholders::error,
					boost::asio::placeholders::bytes_transferred));
		}
		else
		{
			std::cout << "handle_write_stream: " << err << std::endl;
			delete this;
		}
	}

	Peer& peer()
	{
		return peer_;
	}

};


class Echo_Server {
private :
	boost::asio::ip::tcp::acceptor acceptor_;

	void new_handler()
	{
		Stream_Handler *handler = new Stream_Handler(acceptor_.io_service());
		acceptor_.async_accept(handler->peer(), boost::bind(&Echo_Server::handle_accept, this, 
			handler, boost::asio::placeholders::error));
	}

public :
	Echo_Server(boost::asio::io_service &io_service, short port)
		: acceptor_(io_service, boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), port))
	{
		new_handler();
	}

	void handle_accept(Stream_Handler *handler, 
		const boost::system::error_code &err)
	{
		if( !err )
		{
			handler->open();
			std::cout << "New client accepted: " << 
                               handler->peer().remote_endpoint().address().to_string() << std::endl;
			new_handler();
		}
		else 
		{
			std::cout << "handle_accept: " << err << std::endl;
			delete this;
		}
	}

};


int _tmain(int argc, _TCHAR* argv[])
{
	short port = 9088;
	try {
		boost::asio::io_service io_service;
		Echo_Server echo_server(io_service, port);
		io_service.run();
	} catch(std::exception &e) {
		std::cout << "Unexpected error: " << e.what() << std::endl;
	}
	return 0;
}

3. Boost.Asio 비동기(asynchronous) 오퍼레이션
Boost.Asio의 비동기 오퍼레이션을 사용한다는 것은 비동기 오퍼레이션이 완료되었을 때, 콜백을 받을수 있는 객체(또는 함수)가 존재한다는 뜻입니다. 

io_service.run();

위 코드는 Boost.Asio 비동기 오퍼레이션을 수행하기 위한 중요한 부분인데, 콜백 핸들러는 오직 현재 boost::io_service::run() 함수를 호출한 쓰레드로부터 호출됨을 보장해 줍니다. 따라서 위 코드가 실행되지 않았다면, 비동기 오퍼레이션의 완료 콜백은 절대 일어나지 않습니다.

또한,  boost::io_service::run() 함수를 호출하기 전에 io_service 객체에 무언가 작업(비동기 오퍼레이션)을 걸어 주는것은 중요합니다. 아무 할일이 없다면 boost::io_service::run() 함수를 곧바로 리턴되기 때문입니다.
반대로, boost::io_service::run() 함수는 아직 작업(비동기 오퍼레이션)이 남아있는 동안에는 리턴되지 않습니다.


4. 멀티쓰레드 환경에서 콜백 핸들러 동기화
위 코드에서는 boost::io_service::run() 함수의 호출이 하나의 쓰레드(메인 쓰레드)에서만 이루어 집니다. 이것은 콜백 핸들러가 동시에 실행되지 않음을 의미합니다,.(boost::io_service::run()함수를 호출한 쓰레드에서 콜백 핸들러가 실행되기 때문)
이와 같이 boost::io_service::run()함수의 호출을 싱글쓰레드로 제한하는 것이 보통 최선의 방법의 방법으로 여겨질수 있으나, 다음과 같은 단점이 있습니다.

  • 콜백 핸들러의 처리가 늦어지면, 전체 응답시간이 늦어집니다.
  • 멀티프로세서 시스템의 장점을 이용할 수 없습니다.

실제로 위와 같은 문제와 만난다면, boost::io_service::run()함수를 다수의 쓰레드에서 호출하는 방법을 사용할 수 있습니다. 하지만 이것은 콜백 핸들러가 공유자원에 동시 접근이 가능한 것을 의미하며, 공유자원에 대한 접근을 동기화해야 합니다.

boost::asio::strand

boost::asio::strand는 콜백 핸들러의 엄격한 순차적 호출을 보장해줍니다. 즉, 이것을 사용함으로서, 코드의 실행은 명시적인 Locking이 필요없어 지게 됩니다.(뮤텍스 호출과 같은)  오직 하나의 쓰레드에서 boost::io_service::run()함수를 호출하는 것은 모든 콜백 핸들러가 암시적인 boost::asio::strand안에서 실행된다는 것을 의미합니다. io_service는 핸들러가 오직 boost::io_service::run()을 통해서만 호출되는 것을 보장해주기 때문입니다.
Posted by devop

댓글을 달아 주세요

프로그래밍/C/C++2010. 1. 28. 17:49
C++에서 동적 객체를 생성하기 위해 일반적으로 new 연산자를 사용하는데, new 연산자는 2가지의 동작단계를 지니고 있습니다.

  • 요청한 타입의 객체를 담을수 있는 크기의 메모리를 할당한다.
  • 객체의 생성자를 호출하여 할당된 메모리에 객체의 초기화를 수행한다.

new 연산자의 첫번째 동작단계, 즉 요청한 타입의 객체를 담을수 있는 크기의 메모리 할당은 내부적으로 operator new 라는 함수를 호출하여 이루어집니다.

 void * operator new(size_t size)

operator new함수의 반환타입은 void * 입니다. 즉, operator new는 malloc함수와 마찬가지로 메모리만 할당하는 것뿐입니다. 객체니 생성자니 하는것은 operator new와는 전혀 관계없는 것들일뿐이며, 할당된 메모리를 받아 온전한 객체를 생성하는 것은 new 연산자의 몫입니다.

우리는 new 연산자에 대해 재작성이나 오버로딩을 할 수 없지만, operator new 연산자는 재작성, 오버로딩을 할 수 있는데 이를 통하여 자신만의 커스터마이징된 메모리 관리 시스템을 개발할 수 있습니다.(operator new를 오버로딩 할 때에는 size_t이외의 매개변수를 추가할 수 있는데, 이럴때도 첫번째 매개변수는 언제나 size_t 타입이여야 합니다.)


1. placement new
operator new(또는 malloc)을 통해 할당은 받앗지만 초기화되지않은 메모리가 있을때, 우리는 바로 이 메모리 위해 객체를 초기화시킬 수 있습니다. 이를 placement new라 합니다. placement new를 실행하기 위해 준비해야할것은 #include<new>를 추가하는 것이 전부입니다.
MyClass *mem = static_cast<MyClass*>(operator new(sizeof MyClass));
new (mem) MyClass();
위 코드에서 new (mem) MyClass() 부분이 placement new 연산자 입니다. 문법이 조금 이상하지만 operator new 연산자에 매개변수가 1개 더 추가 되었다고 보면 됩니다.

 void * operator new(size_t, void *location)

new, operator new, placment new에 대해 정리하면 다음과 같습니다.

  • 어떤 객체를 heap에 생성하기 위해서는 new 연산자를 사용합니다.
  • 메모리만을 할당하고 싶을 경우에는 operator new 함수를 사용합니다. 즉, 만약에 heap 객체의 생성을 도맡는 메모리 할당 매커니즘을 손보고 싶다면, operator new를 직접 작성하면 됩니다. new 연산자는 operator new 함수를 호출하게될 것이며 호출된 operator new함수는 개발자가 새롭게 작성한 함수입니다.
  • heap에서 직접 메모리를 가져오지 않고, 개발자가 지정한(이미 가지고 있는) 메모리를 사용하게 하려면 placement new를 사용합니다.


2. delete, operator delete
메모리 누수를 막기 위해서는, 할당한 메모리는 반드시 그에 대응되는 메모리 해제를 통해 운영체제에 돌려줘야 합니다. C++에서는 기본적으로 제공되는 delete 연산자를 사용하게 됩니다. 그런데 delete 연산자도 new 연산자와 마찬가지로 내부적으로 어떤 함수를 호출하게 되있습니다.

 void operator delete(void *dealloc)

new 연산자를 통해 할당된 메모리는 delete 연산자를 통해 해제해야합니다. delete 연산자는 객체의 소멸자를 호출하고 객체가 차지하고 있던 메모리를 운영체제에 반환하게 됩니다.

여기서 주의해야할점은, 미초기화된(객체가 생성되지 않은) 메모리를 가지고 어떤 일을 할때에는 new와 delete 연산자를 사용하지 않아야 합니다. 그 대신 메모리를 얻을때에는 operator new를 메모리를 해제할때는 operator delete를 사용합니다.(마치 malloc함수를 통해 할당된 메모리를 free함수를 통해 해제하는것처럼)

placement new를 사용한 경우에는 절대로 delete 연산자를 호출하면 안됩니다. 이유는 delete 연산자는 operator delete를 호출하여 메모리를 해제하지만, placement new에서 사용된 메모리는 원천적으로 operator new를 통해 할당된 것이 아니기 때문입니다. 대신 객체의 소멸자를 직접 호출해주고 메모리도 역시 직접 할당한 방법에 따라 해제해줘야 합니다.
MyClass->~MyClass();
operator delete MyClass;
이와 같이 C++에서 기본 제공하는 new, delete 연산자의 동작방식을 직접 손댈수는 없지만 이들 연산자가 내부적으로 호출하는 operator new, operator delete 연산자는 개발자가 마음먹은대로 고칠 수 있으며, 이는 프로그램의 전첵 메모리 할당 매커니즘을 총괄하는 강력한 메모리 매니지먼트 시스템을 개발할 수 잇음을 의미합니다.
Posted by devop

댓글을 달아 주세요

프로그래밍/C/C++2009. 9. 17. 10:32
C++에서는 new연산자를 통해 객체를 생성한 경우 memory leak을 막기 위해 객체의 사용이 끝난 후 반드시 delete연산자를 호출해야 합니다. 이론은 쉽지만 프로그래밍의 세계에서는 수많은 변수와 예외로 인해 이러한 기본적인 원칙을 지키기가 참 어렵습니다.

이처럼 골치아픈 C++ 메모리 관리에 도움을 줄 수 있는 std::auto_ptr 템플릿에 대해 정리해보겠습니다.

1. auto_ptr ?
auto_ptr은 C++ 표준 템플릿 라이브러리(Standard Template Library, STL)에서 찾을수 있습니다. STL은 C++에서 사용할 수 있는 컨테이너 클래스와 알고리즘, 자료구조를 일반화시켜 제공해주는 라이브러리 입니다. STL은 제네릭 라이브러리라고도 불리며, 이러한 일반화를 구현하기 위해 C++에서 제공하는 Template를 사용합니다. auto_ptr은 바로 이 STL의 구성요소중에 하나로서 스마트 포인터의 여러종류 중에 하나입니다.

* STL에는 auto_ptr이 유일한 스마트 포인터 입니다. boost 등의 라이브러리는 다양한 종류의 스마트 포인터를 제공합니다.


2. 스마트 포인터란?
스마트 포인터란 C++에서 제공하는 기본 포인터 자료형을 흉내내면서 거기에 더불어 부가적인 기능을 가지고 있는 C++ 객체로, 주로 operator->, operator* 연산자를 오버로딩하는 방법을 통해 구현됩니다. 주요 특징으로 포인터에 대한 소유권 관리 기능이 있는데, 소유권을 관리하는 방법은 꽤 다양하며 이에따라 스마트 포인터의 종류도 여러가지가 있습니다.

auto_ptr의 경우 소유권을 자동이전해주는 스마트 포인터로서, 포인터를 복사할 경우 원래의 스마트 포인터는 null을 지정하게 되고, 복사를 받은 스마트 포인터가 해당 포인터에 대한 소유권을 가지게 됩니다.


3. 사용예
class Widget;
void other_func();	// maybe, throw exception
int some_func() {
	Widget *w = new Widget;
	if (...) {
		delete w;
		return -1;
	}
	other_function();
	delete w;
	return 0;
}
위와 코드를 살펴보겠습니다. 
Widget 객체에 대한 포인터는 new 연산자를 통해 할당되었으므로, 반드시 delete를 호출해주어야 memory leak이 발생하지 않습니다. 하지만 위의 코드에서는 Widget 객체 포인터가 delete되지 않을 가능성이 있습니다.

바로 9라인의 other_function() 메소드가 예외를 던지게 된다면 10라인의 delete 코드는 수행되지 않으며, some_func() 메소드가 리턴될 것입니다. 이는 명백하게 memory leak을 발생시키는 원인이 됩니다.

이러한 문제를 방지하기 위해서는 다음과 같이 other_func() 메소드에서 던질수 있는 예외를 처리하기 위해 try-catch 구문을 추가합니다.
class Widget;
void other_func();	// maybe, throw exception
int some_func() {
	Widget *w = new Widget;
	if (...) {
		delete w;
		return -1;
	}
	try {
		other_function();
	} catch (other_function_exception& e) {
		delete w;
		throw;
	}
	delete w;
	return 0;
}
하지만 위의 코드는 무언가 깔끔하지 못한 느낌을 주며, 예외를 던질 수 있는 메소드에 대해 무조건 try-catch 구문을 남발하는 것도 좋은 방법은 아닙니다. 

바로 이러한 문제에 대한 정확하고 깔끔한 해결책을 제시해줄 수 있는 것이 auto_ptr입니다.
#include <memory>
class Widget;
void other_func();	// maybe, throw exception
int some_func() {
	std::auto_ptr<Widget> pw(new Widget);
	if (...) {
		return -1;
	}
	other_function();
	return 0;
}
어떻게 위의 코드는 자동으로 메모리를 반환하는 것일까요? 
바로 local에 생성된 객체는 stack unwinding시에 항상 파괴가 보장된다는 점을 이용한 것입니다. 따라서 return이나 throw의 stack unwinding시에 local 객체인 pw의 소멸자가 호출되게 되고 이때 auto_ptr는 자신이 가지고 있는 pointer를 delete하게 됩니다.

auto_ptr은 다음과 같은 특징을 지니고 있습니다.

  • auto_ptr의 소멸자는 자신이 가지고 있는 pointer를 delete합니다.
  • release() 함수는 자신이 가지고 있는 pointer의 제어를 다시 일반 포인터로 넘겨줍니다.
  • reset(X* p = 0) 함수는 현재 자신이 가지고 있는 pointer를 delete한 후 새로운 pointer의 제어를 가집니다.
  • get() 함수는 자신이 가지고 있는 pointer의 값을 알려줍니다.
  • auto_ptr가 복사될때는 원본이 되는 auto_ptr는 더이상 pointer의 소유권를 가지지 않게 됩니다. (대신 원본 auto_ptr는 null pointer를 가지게 됩니다.)

코딩시 자신도 모르게 auto_ptr의 소유권이 바뀌는 일을 방지하고자 할 경우에는 const auto_ptr idiom을 사용하시면 됩니다. 다음 코드를 참고하세요.
const auto_ptr<T> pt1(new T);

auto_ptr<T> pt2(pt1);	// error
auto_ptr<T> pt3;
pt3 = pt1;		// error
pt1.release();		// error
pt1.reset(new T);	// error
마지막으로 표준에 정의된 auto_ptr은 다음과 같습니다.
namespace std {
	template<class X> class auto_ptr {
		template <class Y> struct auto_ptr_ref {};
	public:
		typedef X element_type;
		// construct/copy/destroy:
		explicit auto_ptr(X* p =0) throw();
		auto_ptr(auto_ptr&) throw();
		template<class Y> auto_ptr(auto_ptr<Y>&) throw();
		auto_ptr& operator=(auto_ptr&) throw();
		template<class Y> auto_ptr& operator=(auto_ptr<Y>&) throw();
		~auto_ptr() throw();
		// members:
		X& operator*() const throw();
		X* operator->() const throw();
		X* get() const throw();
		X* release() throw();
		void reset(X* p =0) throw();
		// conversions:
		auto_ptr(auto_ptr_ref) throw();
		template<class Y> operator auto_ptr_ref<Y>() throw();
		template<class Y> operator auto_ptr<Y>() throw();
	};
}
Posted by devop

댓글을 달아 주세요

프로그래밍/C/C++2009. 8. 20. 17:32
포인터와 레퍼런스는 분명 차이가 있는 개념이지만 쉽게 혼용해서 사용할수 있기때문에 초보자들의 경우 많은 오해를 할 수 있습니다. 여느 C/C++ 프로그램들이 그렇듯이 잘못된 포인터, 레퍼런스의 사용은 프로그램을 hang 시키는 아주 심각한 결과를 초래하게 되므로 이에 대한 정확한 이해가 필요합니다.(참고로 C++에서는  포인터, 레퍼런스를 모두 지원하지만 Java, C#과 같은 고수준 언어에서는 레퍼런스만 지원합니다.)

포인터는 C/C++를 공부하는 사람이라면 누구나 아는것처럼 어떤 대상을 가리키는 것입니다.
레퍼런스는 어떤 대상을 지칭하는 또 하나의 이름이라는 의미가 있습니다.

무슨 말장난 처럼 들리겠지만 이 둘 사이에는 다음과 같이 분명하고 확실한 차이점이 있습니다.


1. NULL 포인터는 존재하지만 NULL 레퍼런스는 존재하지 않는다.
포인터는 어떤 대상을 가리킬수 있지만, 아무것도 가리키지 않을수도 있습니다. 후자의 경우 일반적으로 NULL 포인터라고 말합니다. 이와는 대조적으로 NULL 레퍼런스라는 것은 존재하지 않습니다. 이유가 무엇일까요?
레퍼런스란 어떤 대상을 지칭하는 또 하나의 이름이라는 뜻이 있다고 했는데, 여기서 말하는 어떤 대상이랑 반드시 존재하는 것입니다. 어떤 사람이 있다고 할때 이 사람의 이름과 이사람들 지칭하는 많은 별명들이 있을수 있습니다. 별명은 그 사람이 존재할 때 의미가 있는것이지, 존재하지도 않는 사람한테 별명을 붙일수는 없는 노릇이지요.
레퍼런스도 마찬가지 입니다. 존재하지 않는 대상에 대한 레퍼런스 따위는 아무 의미도 없습니다.
int main()
{
	int *a; // 정상
	int &b; // 에러
}
위 코드에서 처럼 초기화를 하지 않는 포인터의 선언은 가능하지만, 초기화를 하지 않는 레퍼런스의 선언은 컴파일러가 에러로 처리합니다. 레퍼런스는 반드시 선언과 동시에 초기화를 해야합니다.(멤버변수일 경우 생성자에서 초기화를 처리해줘야 합니다.)


2. 포인터는 가리키는 대상을 변경할 수 있지만 레퍼런스는 한번 대상을 지칭하면 변경할수 없다.
포인터는 타입만 다르지 않다면 한개의 포인터를 가지고 어떤 대상이든 자유롭게 가리킬수 있습니다.(설사 타입이 다르더라도 가능합니다!)  하지만 레퍼런스에서는 초기화시에 한번 지칭한 대상을 끝까지 변경할 수 없습니다.


만약 어떤 대상이 있고 이 대상을 포인터로 가리켜야 할지 레퍼런스로 참조해야 할지 헷갈린다면 다음과 같은 가이드라인을 따르도록 합니다.

  • 존재할수도 있고 아닐수도 있는 객체라면 이것은 포인터로 가리키게 한다.
  • 객체가 언제나 존재한다면 레퍼런스로 참조한다.
  • 특정 객체를 가리키고 있다가 다른 객체를 가리키고 싶다면 포인터를 사용한다.
  • 특정 객체의 생명주기를 예측할수 없다면 포인터를 사용한다.

보다 자세한 내용은 C++ 프로그래머의 필독서 이펙티브 C++(스캇 마이어스) 1장을 찾아보길 권합니다.
Posted by devop

댓글을 달아 주세요

  1. 지나가는이

    노란글씨가 보이지 않아요...
    좋은내용인데 글씨가 안보여서 건의드립니다..

    2011.12.22 10:38 [ ADDR : EDIT/ DEL : REPLY ]