Asynchronous Agents Library – agent. 1 ( 상태 )

작성자: 임준환( mumbi at daum dot net )

 

Agent 란 무엇인가

개념

 Agent 는 사전적 의미로 동작이나 행위를 행하는 사람이나 사물이라는 뜻을 가지고 있습니다. 그 말 그대로 Asynchronous Agents Library( 이하 AAL ) 의 agent 는 어떤 행위를 하는 객체를 나타냅니다.

 지난 글에서 AAL 이 actor-based programming 이라고 언급한 적이 있습니다. 여기에서 actor 가 바로 agent 를 일컫습니다.

 이해를 돕기 위해 비유를 하자면 agent 는 하나의 작업이라고 생각해도 좋습니다. 그런데 이 작업은 단순히 한 번 처리되는 작업을 말하는 것이 아니라, 어떤 책임이나 역할을 하는 작업입니다. 우리는 멀티 스레드 프로그래밍을 할 때, 이런 개념을 worker 라고 말하기도 합니다.

 예를 들어, 네트워크 프로그래밍을 할 때, 소켓에 연결 요청을 기다리고 요청이 들어오면 연결해주는 역할을 하는 스레드가 필요합니다. 이 스레드는 어떤 책임이나 역할을 하는 작업을 가지고 있습니다. 이 스레드를 객체로 표현하면 agent 라고 할 수 있습니다.

클래스

 실제 개발 시 필요한 agent 클래스는 Concurrency 네임스페이스 안에 존재하고, agents.h 파일 안에 정의되어 있습니다.

 agent 클래스는 추상 클래스로 agent 로 만들 클래스가 상속해야 합니다. agent 클래스의 추상 메소드는 void run() 이고, 반드시 구현해야 합니다.

- 예

#include <iostream>
#include <agents.h>

using namespace std;
using namespace Concurrency;

class TestAgent
	: public agent
{
protected:
	void run()
	{
		wcout << L"running.." << endl;
		this->done();
	}
};

[ 코드1. agent 상속 예 ]

 

agent 의 상태

 agent 는 비 동기 처리를 목적으로 하기 때문에, 내부적으로 스레드를 사용할 수 밖에 없습니다. agent 의 상태란 agent 의 작업을 처리하는 스레드의 상태라고 볼 수 있습니다.

 agent 는 생명 주기를 갖는데, 이 주기는 상태로 표현됩니다.

 처음 agent 상태는 크게 초기 상태, 활성화 상태, 종료 상태로 나눌 수 있습니다. agent 객체를 생성하면 그 agent 는 초기 상태인 created 상태가 됩니다. start() 를 호출하면 Concurrency Runtime 에 의해 해당 agent 가 스케줄 되고 runnable 상태가 됩니다.

 created 나 runnable 상태에서 cancel() 을 호출하여 작업을 취소하면 canceled 상태가 되는데 이는 종료 상태 중 하나입니다.

 위의 그림에서 점선으로 표시된 run() 은 우리가 명시적으로 호출하는 것이 아니라 runnable 상태인 agent 를 Concurrency Runtime 이 호출하는 것을 의미합니다. run() 이 호출되면 활성화 상태인 started 상태가 됩니다.

 만약 모든 작업의 수행이 완료되었으면 done() 함수를 호출하여 종료 상태인 done 상태로 바꾸어야 합니다. 동기화를 위한 wait() 등의 함수는 해당 agent 가 종료 상태 즉, done 이나 canceled 상태가 되어야 반환됩니다.

 agent 생명 주기에서 가장 중요한 것은 순환되지 않는다는 것입니다. 즉, 되돌아 갈 수 없습니다. 한 번 종료 상태를 갖은 agent 객체는 이미 쓸모 없는 객체가 되고 재사용할 수 없습니다. 그러므로 해당 작업을 다시 수행하기 위해서는 새로운 agent 객체를 생성해야 합니다.

 다음은 각 상태에 대한 정의입니다.

agent 상태	설명
agent_created	agent 가 아직 스케줄 되지 않음.
agent_runnable	Concurrency Runtime 이 agent 를 스케줄 하고 있음.
agent_started	agent 가 실행 중임.
agent_done	agent 의 작업이 완료됨.
agent_canceled	agent 가 실행 되기 전에 취소됨.

[ 표1. agent status ]

 이 상태들은 status() 메소드로 알아 낼 수 있습니다. status() 는 동기화되기 때문에 정확한 상태를 반환하지만, 그 상태가 현재의 상태라고 보장할 수 없습니다. 왜냐하면 status() 가 반환된 직 후 agent 의 상태가 바뀔 수 있기 때문입니다.

- 예

코드

#include <iostream>
#include <agents.h>

using namespace std;
using namespace Concurrency;

class TestAgent
	: public agent
{
protected:
	void run()
	{
		wcout << L"running.." << endl;
		this->done();
	}
};

void print_agent_status( agent& a )
{
	wstring status;
	switch( a.status() )
	{
	case agent_status::agent_created:	status = L"agent_created";	break;
	case agent_status::agent_runnable:	status = L"agent_runnable";	break;
	case agent_status::agent_started:	status = L"agent_started";	break;
	case agent_status::agent_done:		status = L"agent_done";		break;
	case agent_status::agent_canceled:	status = L"agent_canceled";	break;
	}

	wcout << status.c_str() << endl;
}

int main()
{
	TestAgent testAgent;

	print_agent_status( testAgent );

	testAgent.start();

	for( int i = 0; i < 10; ++i )
	{
		print_agent_status( testAgent );
	}

	agent::wait( &testAgent );

	print_agent_status( testAgent );
}

[ 코드2. agent 생명 주기 ]

실행 결과 

 

마치는 글

 이번 글에서는 agent 의 개념과 클래스, 그리고 상태에 대해서 알아보았습니다. agent 를 사용하기 위해서는 조금 더 알아야 할 것들이 있습니다.

 조금 더 알아야 할 내용들은 다음 글에 작성해 보도록 하겠습니다.

 

참고

• 그림1. agent 생명 주기 - http://i.msdn.microsoft.com/dynimg/IC338844.png

지난 6월 1일 Microsoft 의 여러가지 제품과 기술이 총 집합하는 행사 REMIX10 입니다. 이날 Visual Studio 2010 공식 팀 블로그는 여러 파트너사 부스와 Visual Studio 2010 제품의 메인 부스에 버금가는 규모로 부스가 운영되었습니다.    

이 날, 클라우드, 모바일, VS2010 등의 큰 테마를 주제로 진행된 다양한 세션 중 단연, Visual Studio 2010 이 참석하신 여러분의 기술적인 욕구를 충분히 충족할 수 있는 시간이 되지 않았나 생각합니다.    

필자는 Visual Studio 2010 이 주는 새로운 기능에 단지 포커스를 맞추지 않습니다. 왜냐하면 기능은 언제든지 보강을 할 수 있기 때문이죠. 그것보다 더 중요한 것은 Visual Studio 2010 이 우리에게 주는 가치입니다. 제가 생각하는 가치관 중에 "가치는 가치를 아는 자만이 가치를 안다"라는 것처럼 Visual Studio 2010 의 가치를 말이죠.    

왜 Visual Studio 2010 이여야만 하는가…?    

Visual Studio 2010 의 장점이라면 바로 통합 환경(IDE-Integrated Development Environment) 를 제공합니다. 하지만 지금의 패러다임은 단순 통합 환경은 더 이상 매력이 없습니다. 왜냐하면 어떤 다른 개발 플랫폼이든 통합 환경을 제공하고 있기 때문입니다.    

감히 이제는 Visual Studio 2010 을 통합 개발 환경이라고 부르지 마십시오. 왜냐하면 Visual Studio 2010 은 라이프 사이클 관리 도구(Lifecycle Management) 입니다. 단순한 개발 영역 뿐만 아니라, 소프트웨어 개발을 위한 착수, 설계, 테스트, 폐기, 운영에 아우르는 모든 일련의 과정이 Visual Studio 2010 으로 모든 것이 가능해집니다.    

또한 기존의 딱딱한 개발 환경은 잊어버리셔도 좋습니다. 어느 누구에게도 자신의 스타일이 있듯이 기존의 개발 도구도 개발 도구만의 스타일이 있었습니다. 하지만 Visual Studio 2010 은 개개인의 스타일에 맞추어 드립니다. 자신에게 착~ 맞는 옷이 가장 뽀대가 나듯이, 자신에게 가장 잘 맞는 개발 도구가 최상의 개발 생산성을 낼 수 있는 것과 같은 이치 입니다.    

   

개발자끼리의 소통 수단은 단지 "코드" 입니까? 코드를 잘 만드는 사람이 고급 개발자이고, 코드를 잘 만들지 못하는 사람이 초급 개발자인 시대는 이미 몇 년 전 이야기 입니다. 코드는 비즈니스 영역의 산출물이지, 코드가 목적이 되어서는 안됩니다.    

코드는 비즈니스 목표를 해석해 놓은 산출물입니다. 결국 코드는 어플리케이션이 잘 동작하도록 설계대로 구현된 산출물입니다. 코드를 어떻게 구현했느냐는 2차적인 수단이며, 코드의 흐름을 파악할 수 있는 것이 더욱 중요합니다.    

Visual Studio 2010 의 강력한 데이터 시각화 기능들은 코드 중심이 아닌, 전체적인 흐름을 파악할 수 있는 통찰력을 제공해 줍니다.    

   

소프트웨어의 버그는 왜 발생하는가….? 필자의 블로그의 [ALM-Test] 왜 단위 테스트를 해야 하는가? [2] 에서 언급했듯이 코드, 클래스, 컴포넌트, 레이어간의 연동 관계가 생성되면서 주로 발생하게 됩니다. 코드의 자체적인 결함 보다는 연동/종속적인 관계가 형성이 되면서 버그는 증식이 됩니다.    

최근 우리나라의 소프트웨어 업계에서 테스트라는 영역은 이전보다 더 큰 관심을 보이고 있습니다. 테스트는 어떻게든 할 수 있지만, 어떻게 가시적이고 올바른 테스트가 가능한 것인가에 대해서 말입니다. Visual Studio 2010 과 Team Foundation Server 2010 그리고 Test & Lab 은 테스트에 대한 방법론을 가장 올바르게 가이드하는 환경을 제공해 줍니다.    

상상해 보셨습니까? 테스트가 생산 공정의 라인처럼 자동화 된다는 것을… 이미 그 상상은 현실이랍니다. ^^    

   

   

Visual Studio 2010 에 대한 문의 사항은 메일 powerumc at gmail.com 또는 트위터 @powerumc, @vsts2010 으로 언제든지 연락을 주시기 바랍니다. 가장 좋은 방법으로 도구와 시스템을 업그레이드 하는 방법이나 기술 업체와 연결하여 드리겠습니다.

새로운 버전의 Visual Studio가 출시되었지만, 설치하는데 시간도 오래 걸리고 새로운 기능을 일일이 테스트해보기 어려우신 분들이 많으실 것입니다. 혹은, Imagine Cup과 같은 IT 경진 대회를 준비하시는 학생 여러분들은 적당한 소프트웨어 개발 도구를 찾을 수 없어 고민이 크실 수 있습니다. 오늘 강좌에서는 이러한 고민을 덜어줄 가볍고 편리한 Visual Studio의 새 버전을 소개해드릴까 합니다.

그 주인공은 바로 Express Edition 입니다. Visual Studio Express Edition은 지난 Visual Studio 2005부터 지속적으로 업데이트되고 있는, 이제는 Microsoft Visual Studio Family의 중요 멤버로 자리잡은 주요 제품군 중 하나가 되었습니다. Express Edition이라는 이름에서 알 수 있듯이, 개발자들에게 가장 핵심적인 Subset을 제공하는 버전입니다. 하지만 그 기능은 "절대 빈약하지 않습니다."

Visual Studio Express Editon은 Visual Studio .NET 2002/2003 제품군이 발표될 무렵까지 유지되어왔던 개별 언어 제품군들에 대한 새로운 묶음 패키지입니다. Visual Basic .NET, Visual C#, Visual C++, Visual Web Developer를 주축으로 하며, 여기에 부수적으로 SQL Server의 Express Edition까지 항상 같이 제공되어왔었습니다. Visual Studio 2005 시절에는, 지금은 지원이 중단되었지만 Visual J#에 대한 Express Edition도 제공되었던 적이 있었습니다.

왜 Express Edition인가?

Visual Studio Express Edition은 단지 공짜로 제공되는 프리웨어이기 때문에 가치가 있는 것은 아닙니다. Microsoft가 발표하는 주요 최신 기술들을 재빨리 시험해볼 수 있는 훌륭한 플랫폼으로 Express Edition의 역할이 점차 옮겨가고 있으며, 대표적인 예가 바로 Visual Studio Express Edition for Windows Phone 7입니다. 그리고 XNA Framework 역시 Express Edition을 기초로 모든 SDK를 제공해왔었습니다.

저 개인적으로는 Express Edition을 매우 애용합니다. Express Edition은 프로토 타이핑 프로그래밍을 할 수 있도록 여러분의 Mental Model을 바꾸어줍니다. Visual Studio를 이용하여 프로그래밍을 시작하는 것은, 사용하는 시스템의 종류에 따라서는 또 하나의 새로운 운영 체제를 로딩하는것과 같은 기분을 느끼게 하여 부담스러울 수 있습니다. 하지만, 전체 기능을 로드하지 않고서 필요한 프로그래밍 언어에 해당되는 IDE만을 로드하기 때문에 훨씬 로딩 속도도 빠릅니다. 그리고, C#과 VB.NET의 경우, 프로젝트를 임시 디렉터리에 생성하는 것을 기본으로 하기 때문에, 여러분의 프로젝트 디렉터리가 지저분해질 걱정을 하지 않고 작은 코드와 프로그램을 시험해보기 위하여 망설임없이 IDE를 켤 수 있습니다. 만약 프로젝트를 실제로 작성하기를 원치 않는다면, 프로젝트를 닫을 때 나타나는 저장 여부 대화 상자에서 단순히 "버리기" 버튼만 클릭하면 됩니다.

LINQPad (http://www.linqpad.net/), Small Basic (http://www.microsoft.com/downloads/details.aspx?FamilyID=61481b74-eb45-42b8-a777-8f3644406787&DisplayLang=ko)과 같은 유틸리티와 다른점을 언급해본다면, 역시 이러한 유틸리티들은 IDE가 아닌, 간단한 도구의 수준 안에 있습니다. 하지만 이러한 도구들로는 충족하기 힘든, 그러나 정식으로 프로젝트를 만들고 코드를 Organizing하는데에 노력이 필요하지 않은 정도의 임시 코드를 작성하고 편안하게 테스트할 수 있는 환경을 찾으신다면 그것이 Express Edition의 역할이라 할 수 있겠습니다.

Express Edition에 관한 몇 가지 중요한 질문과 답변들

아래의 질문 목록들은 Express Edition을 선택하고 활용하는 데에 몇 가지 중요한 기준들이 될 수 있습니다.

A. 불법 소프트웨어 단속에 걸리지 않는 완전한 프리웨어인가? 

예. 다만, 30일 이내에 Windows Live ID를 사용하여 완료할 수 있는 무료 등록 절차를 통하여 Serial Number를 받아 프로그램에 등록해야 합니다. 30일 이후에도 등록되지 않은 상태로 남아있으면 프로그램 시작 시 등록을 하지 않으면 실행되지 않도록 프로그램이 변경됩니다.

B. Express Edition을 이용하여 상용 소프트웨어를 개발할 수 있는가?

예. 또한, 오픈 소스 라이선스 (GPL, LGPL, MPL, BSD 등)를 대상으로 하는 소프트웨어 프로젝트에서도 Express Edition을 사용하는데에 아무런 제약이 없습니다.

C. Crystal Report나 Microsoft Report Designer가 제공되는가?

아니오. 제공되지 않습니다.

D. Visual C++ Express Edition의 경우 MFC나 ATL 프로젝트를 생성하고 GUI를 디자인할 수 있는가?

아니오. MFC나 ATL 프로젝트를 새로 생성하는 기능이 없고, GUI 디자인도 제약이 있습니다. 단, Visual Studio 2010 Professional 이상에서 작성한 Visual C++ Project를 Express Edition에서 기본적인 수준에서 열거나 편집하거나 빌드하는 것에는 환경 설정이 정확하다면 문제가 없습니다.

E. Express Edition을 이용하여 Silverlight Project나 Windows Azure Application을 만들 수 있는가?

예. Silverlight Tools와 Windows Azure Tools 모두 Visual Web Developer의 기능 집합을 이용하여 SDK가 설치되므로 Visual Web Developer Express Edition을 설치하면 Silverlight와 Windows Azure 응용프로그램을 개발할 수 있습니다.

F. Windows Installer 프로젝트를 생성할 수 있는가?

아니오. 다만 ClickOnce 기능은 Visual Basic .NET Express Edition과 Visual C# Express Edition 모두 지원됩니다.

G. 여러가지 서로 다른 종류의 프로젝트를 한 솔루션 안에 포함할 수 있는가?

아니오. 교차 언어 지원은 Express Edition 이상의 버전 (예: Standard / Professional)에서부터 지원됩니다. 다만, 같은 언어끼리 한 솔루션 안에 여러 프로젝트를 생성하고 관리하는 것에는 문제가 없습니다.

Visual Studio 2010 Express Product Feature Chart

아래의 차트를 확인하시면 Visual Studio 2010 Express Edition이 실제로 지원하는 기능들에 대하여 좀 더 직관적으로 이해하실 수 있습니다. (출처: http://www.microsoft.com/express/Downloads/#2010-Visual-Web-Developer)

Visual Studio Express Edition 설치하기

Visual Studio Express Edition을 설치하려면 http://www.microsoft.com/express 에 방문한 뒤 Download 링크를 클릭하여 원하는 제품을 선택하여 웹 설치 마법사를 다운로드하거나, 전체 버전의 DVD ISO 이미지 파일을 다운로드하여 ISO 마운트 프로그램을 이용하여 설치 프로그램을 오프라인에서 실행하는 방법이 있을 수 있습니다. 이 글을 작성하는 현 시점에서 Express Edition에도 한국어 버전이 추가되어, Visual Studio 2010과 .NET Framework 4.0의 최신 기능을 빠르고 간편하게 테스트해보실 수 있습니다.

각각의 제품을 설치하신 뒤에는 30일 이내에 제품 등록을 하셔야 합니다. 제품 등록 이전에는 "평가판"이라는 문구가 나타나지만 등록을 한 이후에는 정품으로 변환되기 때문에 걱정하지 않으셔도 됩니다. 등록하는 과정에서 Windows Live ID가 필요합니다.

Express Edition 화면 미리 보기

이전다음

01234

마지막으로 제안 한 가지

Internet Explorer 6.0을 사용하지 말자는 제안은 정말 널리 퍼져있고, 이제는 어느정도 Internet Explorer 6.0이 왜 문제가 되는지 충분히 공감대가 형성되어있습니다. 하지만, Visual C++ 컴파일러는 어떤가요? 아직도 6.0을 사용하고 계신가요?

서비스 팩 6를 설치했다고 할지라도 Visual C++ 6.0은 Internet Explorer 6.0보다 훨씬 더 오래된 제품입니다. http://en.wikipedia.org/wiki/Visual_C%2B%2B 페이지의 설명에 따르면 Visual C++ 6.0은 1998년에 발표된 제품이고, 이 글을 작성하는 현 시점에서 생각해보면 무려 12년이나 된 제품입니다. http://archvista.net/1328 에서 소개하는 것 처럼, 아직도 Visual C++ 6.0을 사용하신다면 여러분은 12년 묵은 우유를 드시는것과 다름이 없습니다.

이 글을 보시게 될 수도 있을 전산학부 교수님, 조교님, 그리고 학생 여러분들께 부탁드립니다. Visual C++ 6.0에 대한 라이선스를 가지고 있다는 이유만으로, 바꾸기 귀찮다는 이유만으로 과제를 검사하고 테스트하지 말아주십시오. 10년이면 강산도 바뀌는 세월입니다. Visual C++ 컴파일러도 업그레이드가 필요합니다. 전체 버전을 이용하지 않더라도, Visual Studio 2008 또는 2010 Express Edition이 충분한 솔루션이 될 수 있습니다.

긴 글 읽어주셔서 감사합니다. 즐거운 하루 되세요. :-)

- 잡설없이 바로 고고고!

지난 포스트의 마지막 예제에서 Task 클래스의 IsCompleted라는 속성을 사용했었습니다. 이름 그대로, 해당 작업이 끝났는지를 확인할 수 있는 속성인거죠. 이런 속성말고는 또 뭐가 있을까요? 몇 가지 쓸모 있는 속성을 들을 예제를 통해서 확인해보도록 하죠.

using System; using System.Threading.Tasks; namespace Exam4 {     class Program     {         static string Calc(object from)         {             long sum = 0;             long start = (long)from;             Console.WriteLine("현재 이 메서드를 실행중인 스레드 ID : {0}",                 Task.CurrentId);             for (long i = start; i < 100000000; i++)             {                 sum += i;             }             return sum.ToString();         }         static void Main(string[] args)         {             Task<string> task = new Task<string>(Calc, 1L);             task.Start();             Console.WriteLine("추가 스레드의 ID {0}",                 task.Id);             Console.WriteLine("추가 스레드에 제공된 상태 값 : {0}",                 task.AsyncState.ToString());             while (!task.IsCompleted)             {                 if (task.Status == TaskStatus.Running)                 {                     Console.Write(".");                 }             }             Console.WriteLine("");             //여기서 추가 스레드가 끝날 때 까지 기다린다.             Console.WriteLine(task.Result);             System.Diagnostics.Trace.Assert(                 task.IsCompleted);         }     } }

<코드1> 유용한 속성을 사용한 예제

<코드1>은 기본적으로 유용하게 사용되는 속성들을 활용한 간단한 예제입니다. 우선 결과를 볼까요?

추가 스레드의 ID 1 현재 이 메서드를 실행중인 스레드 ID : 1 추가 스레드에 제공된 상태 값 : 1 ................................................................................................................................................................ ................................................................................................................................................................ ................................................................................................................................................................ ................................................................................................................................................................ ................................................................................................................................................................ ................................................................................................................................................................ ............................................................................................................................................................... ................................................................................................................................................................ -중략- ................................................................................................................................................................ ...................................................................................... 4999999950000000 계속하려면 아무 키나 누르십시오 . . .

<결과1> 실행 결과

그럼 속성을 하나씩 확인 해보면서 왜 저런 결과가 나왔는지 확인해보죠.

속성명	설명
Task.CurrentId	현재 Task.CurrentId 호출을 처리하는 스레드의 Id
AsyncState	스레드에 추척가능한 값을 부여한다. 예를 들어서 스레드가 3개가 있고, 각각 1,2,3 이라는 값을 부여했다면, 각각의 스레드의 AsyncState는 1,2,3 이므로 이 값을 다른 용도로 사용할 수도 있고, 스레드를 구별하는데 사용할 수도 있다.
Id	각각의 작업에 부여되는 고유한 Id
Status	현재 작업의 상태를 표시한다. Created, WatingForActivation, WaitingForRun, Running, WaitingForChildrenToComplete, RanToComplete, Canceled, Faulted등이 있다.

<표1> 유용한 속성들

네 각각의 속성을 한번 정리해봤습니다. 어헣. 추가 스레드의 아이디는 1이었죠. 그리고, Calc메서드를 실행하는 스레드도 역시 아이디가 1인 추가 스레드이기 때문에, Calc메서드 안에서 Task.CurrentId로 현재 실행중인 스레드의 아이디를 출력하면 1이 출력되는 것이구요. 스레드를 생성하면서, 상태값으로 1을 넘겨줍니다. 그래서, 그 상태값을 Calc메서드 내부에서 받아서 사용하기도 하고, 추후에 스레드의 상태값을 출력해볼 수도 있는 것이죠.


- 스레드 자세히 들여다 보기

그럼 비주얼 스튜디오에 새로 추가된 툴을 이용해서, 어떤 스레드가 생성되는지 한번 확인해보도록 하겠습니다. 아마, 뒤에서 더 자세하게 설명드리겠지만, 오늘은 그냥 간단하게 살펴보는 정도로 하도록 하죠. <코드1>에 아래와 같이 코드를 추가합니다.

Debugger.Break(); Console.WriteLine("추가 스레드의 ID {0}",     task.Id); Console.WriteLine("추가 스레드에 제공된 상태 값 : {0}",     task.AsyncState.ToString());             while (!task.IsCompleted) {     if (task.Status == TaskStatus.Running)     {         Debugger.Break();         Console.Write(".");     } }

<코드2> 수정한 코드

Debugger클래스는 System.Diagnostics에 정의되어 있는데요, 브레이크 포인트를 걸지 않아도, Break메서드가 호출된 곳에서 실행을 멈추고 디버거를 사용할 수 있습니다. 다만, 그냥 Debug모드로 놓고 컴파일하지 않고 실행(Ctrl + F5)을 하면, 계속 에러가 나니 주의하시구요.

우선 F5로 실행을 하신다음에, 첫번째 브레이크 포인트에 걸리면, '디버그'메뉴에서 '창'메뉴로 들어가서 '스레드', '병렬스택', '병렬작업'을 띄웁니다. 그리고 '스레드'를 보면,

<그림1> 스레드 창

다음과 같이 현재 떠있는 스레드의 목록을 볼 수 있습니다. 저 중에, '.NET SystemEvents'라고 된 스레드는 이벤트의 발생을 주시하고 있는 스레드이구요, 'vshost.RunParkingWindow'라고 된 스레드는 비주얼 스튜디오 호스팅 프로세스입니다. 그리고 '주 스레드'는 현재 Main메서드를 실행 중인 스레드를 말하구요. 그리고 ID가 4112라고 된 스레드가 추가로 생성한 스레드입니다. 어째서 그런지 확인을 해볼까요? 병렬 스택 창을 한번 확인해보죠.

<그림2> 병렬 스택 창

위 그림은 병렬 스택 창에서 스레드 그룹의 제목('4개 스레드'라고 쓰인 부분)에 마우스를 올리면 어떤 스레드가 있는지 보여주는 장면입니다. 총 3개의 스레드가 있는데, 앞에서 설명드린 3개의 스레드외에 작업자 스레드가 하나 있는 걸 보실 수 있습니다. 바로 저 스레드가 우리가 추가로 생성한 스레드인거죠. 그런데, 호출 스택에 Main메서드를 실행하는 주 스레드만 한 단계 진행한 걸 볼 수 있는데요, 그렇다면 아직 추가 스레드에 작업이 물린 상태는 아닌 것 같습니다. 그러면, F5키를 눌러서 다음으로 넘어가 볼까요? 그리고 병렬 스택을 보면,

<그림 3> 바뀐 병렬 스택 창

이미 추가 스레드도 작업에 들어간 상태이다 보니, 추가 스레드가 한 단계 더 진행해서, Calc메서드를 실행하고 있다고 나옵니다. 그리고 병렬 작업 창을 한번 볼까요?

<그림 4> 병렬 작업 창

상태는 실행 중(== TaskStatus.Running)이고, 할당된 스레드는 4112번 작업자 스레드라는 걸 확인할 수 있습니다. 이런 디버깅 툴을 잘 활용하면, 복잡한 병렬 프로그래밍을 하는 데 좀 더 편안하게 작업할 수 있겠죠? 이 디버깅 툴에 대해서는 나중에 좀 더 자세하게 설명드리도록 하지용.


- 마무리

앤더스 헬스버그는 C#에 영향을 미치는 3대 트렌드가 선언적, 동시적, 동적 프로그래밍 이라고 했는데요, 선언적 프로그래밍은 이미 LINQ를 통해서 편하게 지원되고, PLINQ로 확장이 되었죠. 그리고 동적 프로그래밍은 dynamic타입과 DLR을 통해서 지원이 되구요. 그리고 동시적 프로그래밍은 TPL과 이런 다양한 툴을 통해서 좀 더 제대로된 지원을 하고 있습니다. 제대로만 쓴다면, 비주얼 스튜디오 2010에서 쫌 편하게 작업할 수 있겠네요. 늘 문제가 되는건 제대로 쓸 줄도 모르면서 불평만 하는 저 같은 양민이져 어헣-_-.


- 참고자료

1. Essential C# 4.0, Mark Michaelis, Addison Wesley
2. http://msdn.microsoft.com/en-us/library/dd554943.aspx
3. http://msdn.microsoft.com/en-us/library/microsoft.win32.systemevents.aspx
4. http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/f8ccec3a-25db-4d3b-a90a-e758f6243356/

- 작업해본 적이나 있수?

물론이죠-_-;; 이 나이에 작업해 본 적도 없으면, 마법사 정도가 아니라, 신이 됐겠죠. 어헣. 오늘의 작업은 그 작업은 아니고... 스레드와 관련된 작업입니다. 부디 오해 없으시길 바라고, 작업의 기본은 다른 연예 서적에서 얻으시길.


- Task 시작하기.

지난 포스트에서 했던 예제를 한번 돌아보겠습니다.

using System; using System.Threading.Tasks; namespace Exam2 {     class Program     {         static void Main(string[] args)         {             const int max = 10000;             //현재 작업중인 스레드외에 추가로 스레드를 생성             Task task = new Task(() =>                 {                     for (int count = 0; count < max; count++)                     {                         Console.Write("|");                     }                 });             //추가 스레드 시작             task.Start();             //현재 작업중인 스레드에서도 반복문 시작             for (int count = 0; count < max; count++)             {                 Console.Write("-");             }             //혹시 현재 스레드가 빨리 끝나더라도,             //추가 스레드가 끝날 때 까지 기다리기.                        task.Wait();         }     } }

<코드1>

Main메서드를 실행하는 스레드 외에 또 하나의 스레드를 추가로 생성해서, 두 개의 스레드로 화면에 다른 문자열을 출력하는 예제였죠. 이 예제를 보면, Task라는 클래스를 사용하고 있습니다. 이 클래스는 닷넷 프레임워크 4.0에 새롭게 추가된 클래스인데요. 기존의 멀티스레드 프로그래밍을 한 단계 높은 추상화를 통해서 프로그래머의 실수를 줄이고, 좀 더 직관적인 코드를 작성할 수 있게 해주는 TPL(Task Parallel Library)에 포함되어서 추가된 클래스입니다. 중심에 있는 클래스라고 볼 수 있죠.

Task클래스는 관리되지 않는 스레드를 한단계 감싸서 추상화를 시킨 클래스입니다. 내부적으로 스레드 풀을 사용하는 데요, 내부적으로는 System.Threading.ThreadPool을 사용해서 요청에 따라 스레드를 새로 생성하거나, 이미 생성된 스레드를 재활용해서 부하를 줄입니다.

새로운 Task가 실행할 동작은 델리게이트를 통해서 명시해주는데요, <코드1>에서 굵게 처리된 부분이 바로 그 부분입니다. 카운트에 따라서 문자열을 출력하는 델리게이트를 생성자에 넘겨주고 있는 거죠. 물론, 이렇게 델리게이트를 넘겨준다고 해서 바로 스레드가 실행되는 건 아닙니다. Start메서드를 통해서 실행을 해줘야만 스레드가 실행되는 것이죠.


- Task가 끝날 때?

그러면, <코드1>은 두개의 스레드가 실행이 되면서 서로 다른 문자열을 번갈아 가면서 출력하겠죠. 여기서 한가지 생각해볼게 있습니다. 콘솔 어플리케이션은 Main메서드의 실행으로 시작하고, Main메서드의 끝과 함께 종료됩니다. 그렇다면, Main메서드의 실행을 맡은 스레드가 종료되었는데, 추가로 생성한 스레드의 작업이 안끝났다면 어떤 일이 벌어질까요?

//현재 작업중인 스레드외에 추가로 스레드를 생성 Task task = new Task(() =>     {         for (int count = 0; count < max; count++)         {             Console.Write("|");         }         Console.WriteLine("추가 스레드 끝");     }); //추가 스레드 시작 task.Start(); //현재 작업중인 스레드에서도 반복문 시작 for (int count = 0; count < max; count++) {     Console.Write("-");                } Console.WriteLine("메인 스레드 끝"); //혹시 현재 스레드가 빨리 끝나더라도, //추가 스레드가 끝날 때 까지 기다리기.            //task.Wait();

<코드2>

<코드1>을 <코드2>와 같이 수정한 다음에 실행해보죠. 그러면, 둘 중의 어떤 스레드가 빨리 끝날까요? 그건 그때 그때 다릅니다-_- 그래서 아래와 같은 두 경우가 생길 수 있죠.

||||-----||||||||--------------|||||||||||||-------------||||||||||||-----------||||||---------------||||||||||||------------|||||||||||-----------||||||||||||--|||||||||||||-------|||||||||||-------------||||||||||||--------------||||||||||----------------|||---------------||||||||||||||-----||-------------||||||||||||----------------|||||||||||||-------------||||||||||||-------------|||---|------||||||||||||||-----------------|---------------||||||||||||||---------------메인 스레드 끝 |계속하려면 아무 키나 누르십시오 . . .

<결과1> 메인스레드가 먼저 끝나는 경우

|----------------|||||||||||||-----------||||||||||||||---------||||||||||||-----||||||||||||||||---------------||||||||||||||--------------||-----------||||||||------------|||||||||||||||-------------|--------------|||||||-------------|||||---||추가 스레드 끝----------------------------------------------------------------------------------------------------------------------------------------------------------메인스레드 끝 계속하려면 아무 키나 누르십시오 . . .

<결과2> 추가 스레드가 먼저 끝나는 경우

<결과2>는 추가 스레드가 먼저 끝나면서 모든 결과가 출력이 되었지만, <결과1>은 Main메서드의 실행을 맡은 메인 스레드가 먼저 끝나면서 프로그램이 종료되었고, 따라서 추가스레드의 나머지 결과는 날아가 버렸습니다. Wait메서드는 메인 스레드가 먼저 끝나더라도, 추가 스레드가 끝날 때까지 기다리게 하는 역할을 합니다. 그래서 메인 스레드가 빨리 끝나더라도, 항상 추가 스레드의 결과까지 제대로 출력되게 되는 것이죠.

||||||||--------|||||||||||||||--------------|||||||||||||------------|||||||||||||--------|||| ||-메인 스레드 끝|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||추가 스레드 끝 계속하려면 아무 키나 누르십시오 . . .

<결과3> Wait메서드를 사용한 경우


- 가는 길은 여러갈래.

앞에서 스레드의 시작은 Start메서드를 통한다고 말씀 드렸지만, 항상 그런 것은 아닙니다. 생성과 동시에 실행을 시킬 수도 있습니다.

Task task = Task.Factory.StartNew(() =>                 {                     for (int count = 0; count < max; count++)                     {                         Console.Write("|");                     }                     Console.WriteLine("추가 스레드 끝");                 });

<코드3> 생성과 동시에 스레드 시작

<코드1>의 Task생성 부분을 <코드3>과 같이 수정하고, Start메서드 호출부분을 주석처리하면, 동일한 결과를 얻을 수 있습니다.

그리고 <코드1>에서는 메인스레드가 추가 스레드가 끝날 때까지 기다리기 위해서 Wait메서드를 사용했지만, 다른 방법도 있습니다. 만약에 추가 스레드에 입력된 델리게이트가 결과값을 반환하고, 메인 스레드에서 그 결과값을 사용해야 한다면, 메인 스레드는 추가 스레드의 작업이 끝나서 결과가 나올 때까지 기다립니다. Wait메서드 없이도 말이죠. 어찌보면 당연한 이야기죠 ㅋ

using System; using System.Collections.Generic; using System.Threading.Tasks; namespace Exam3 {     class Program     {         static void Main(string[] args)         {             Task<string> task = Task.Factory.StartNew<string>(                 () =>                 {                     long sum = 0;                     for (long i = 0; i < 100000000; i++)                     {                         sum += i;                     }                     return sum.ToString();                 });             foreach (char busySymbol in BusySymbols())             {                 if (task.IsCompleted)                 {                     Console.WriteLine('\b');                     break;                 }                 Console.WriteLine(busySymbol);             }             Console.WriteLine();             //여기서 추가 스레드가 끝날 때 까지 기다린다.             Console.WriteLine(task.Result);             System.Diagnostics.Trace.Assert(                 task.IsCompleted);         }         private static IEnumerable<char> BusySymbols()         {             string busySymbols = @"-\|/-\|/";             int next = 0;             while (true)             {                 yield return busySymbols[next];                 next = (++next) % busySymbols.Length;                 yield return '\b';             }         }     } }

<코드 4> 결과 기다리기.

<코드4>는 추가 스레드의 결과를 계속 기다리다가, 결과가 나오는 순간, 출력하고 끝납니다.


- 멀티스레드 쉽고만?

이라고 생각하시면 곤란하구요-_-;; 열심히 공부 중인데, 역시 어렵습니다. 다만, Task클래스가 상당히 많은 부분을 간소화 시켜 주기 때문에, 한 층 더 편해진 느낌이랄까요? 오늘 여기까지!


- 참고자료

1. Essential C# 4.0, Mark Michaelis, Addison Wesley

안녕하세요. 지난 포스팅에 이어서(넘흐 오랜만이죠^^;) 시작하겠습니다. 아마 다들 잊으셨을 겁니다. 여기까지 했었죠?


_db.SaveChanges() 를 하려 했더니, 에러가 발생했습니다. 자세히 들여다 보니


ID 에 NULL 값을 넣을 수가 없다네요. 이래서 에러가 발생했죠.
아~ 이래서 사용자가 빈 값을 넣으려 하면 막아야하겠구나~ 라는 생각이 번뜩 드셨을겁니다.

유효성 검사!

유효성검사라 하면 필수입력값에는 꼭 데이터를 입력해야하고, 데이터의 타입이나 길이에 맞게 들어오게 체크하는 것을 말하겠죠?

ASP.NET MVC 프레임워크에서는 모델 스테이트(Model State)를 제공합니다. 정확히 말하면 model state dictionary 라고 해서 유효성 에러들을 표시하기 위해 사용됩니다. 유효성 검사중에 해당 프로퍼티에서 fail 이 발생하면 모델 스테이트에 이를 추가합니다. 모델 스테이트에 에러가 있으면 ModelState.IsVaild 는 false를 반환합니다.
여기까지 설명을 드리고, 예제와 함께 보시겠습니다.

예제 만들기

아주 간단한 전화번호를 담는 TelDir 클래스를 만들겠습니다.


DirectoryController 도 추가하겠습니다. 이 컨트롤러에 두개의 Create 액션메쏘드를 만들겠습니다. 하나는 /Directory/Create url 요청시(GET) 호출되는 메쏘드이고, 다른 하나는 POST로 호출되는 메쏘드 입니다. 아시죠?^^
ASP.NET MVC 프레임워크에서는 자동적으로 폼 필드에 값을 해당 모델 속성들과 매핑을 시킵니다. 모델 바인더가 이런 일을 하게되죠. 예제에서 처럼 HTML 폼 필드의 값을 TelDir 객체에 매핑을 시키는데, 에러가 없이 바인딩이 되면 즉, ModelState.IsValid가 true 이면 데이터베이스에 저장을 하는 것이고, 그렇지 않다면, 다시 폼을 그리며 에러를 표시하게됩니다.


뷰도 같이 만들겠습니다. 액션메쏘드에서 오른쪽버튼을 클릭하여 Add View 를 선택하고, 강하게 생성하겠습니다.


추가하기 전에 빌드하는 것 잊지 않으셨죠? 모델 생성 후 빌드를 하지 않으면 View data class 항목에 표시가 되지 않습니다. Add 해서 완료를 하시면 /Views/Directory/Create.aspx 가 생성되었습니다.


휴. 여기까지 했으니 이제 유효성검사를 해보실까요?
다음과 같이 컨트롤러에서 유효성 검사를 할수 있습니다.


물론, 클라이언트단인 aspx 에서도 할 수 있겠죠. 제가 프로젝트에서 경험해본 유효성검사는 클라이언트단에서 먼저 검사를 하고 혹시나 몰라서, 클라이언트에서의 유효성검사를 신뢰할수 없어서 서버단에서도 한번 더 유효성검사를 했었습니다. 코드가 중복되고 또한 비슷한 UI 에서도 같은 검사를 해야했었죠.
ASP.NET MVC 에서는 이러한 부분을 모두 없애고 모델클래스에서 이를 담당하게 합니다. 심플해지고 개발속도도 향상되죠.

DataAnnotation을 이용한 유효성 검사


위와같이 컨트롤러와 뷰가아닌 모델에 유효성 검사로직을 두게되면, 다른 UI(Edit와 같은) 에서도 따로 유효성 검사를 하지 않고도 동일한 유효성 검사를 할 수 있습니다. 이렇게 함으로써 중복되는 코드를 피할 수 있게되는 거죠. DRY관점에서도 올바른 방향으로 나가는 거겠죠?ㅡ.ㅡ

위 소스를 보시면 유효성 검사를 위한 몇개의 속성들이 눈에 띄실겁니다.  using 문에 System.ComponentModel.DataAnnotations를 추가하면 유효성 검사 속성들을 사용할 수가 있습니다. 
각 필드에 속성들을 추가할 수 있는데요. [Required], [Ragng], [ReqularExpression], [StringLength] 등이 있고 커스텀한 속성도 만들 수가 있습니다.
만약 Name 에 길이제한을 5자로 하고 싶다면 [StringLength(5, ErrorMessage="5자까지만!")] 을 추가만 하시면 됩니다. 모델의 유효성 검사를 추가함으로(컨트롤러와 뷰 수정없이), 이 모델을 사용하는 부분에는 모두 적용이 되는거죠. 참 쉽죠잉?

일단 에러를 내볼까요?


위 에러메시지가 표시되는 것은 Create.aspx 소스를 보시면


<%: Html.ValidationMessageFor() %> 를 보실 수 있습니다. 바로 이것이 ModelState.IsValid 가 false 여서 뷰를 다시 그릴때, 각각의 해당 필드 옆에 붙어서 에러메시지를 보여주는 유효성 검사 헬퍼 메쏘드 입니다.

여기서 마무리

바로 지난번에 이어 계속 진행하고 싶지만, 유효성 검사에 대해 설명하다보니 이것만으로 너무 길어져서 오늘도 여기서 마무리 하겠습니다(__). 곧 찾아뵙도록 하겠습니다. ^^

참고 : http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx

Asynchronous Agents Library 소개

작성자: 임준환( mumbi at daum dot net )

 

Concurrency Runtime 의 컴포넌트

 Asynchronous Agents Library 는 위 그림에서 보듯이 Concurrency Runtime 프레임워크 안에서 돌아가는 내부 컴포넌트 중 하나입니다.

 라이브러리라는 명칭에서 독립적으로 수행될 것 같은 오해를 가질 수 있으나, 사실은 Concurrency Runtime 의 Task Scheduler 와 Resource Manager 를 기반으로 만들어졌습니다.

 Concurrency Runtime 에서 Task Scheduler 와 Resource Manager 를 하위 레벨 컴포넌트라고 본다면, Asynchronouse Agent Library( 이하, AAL ) 와 Parallel Patterns Library( 이하, PPL ) 은 상위 레벨 컴포넌트라고 볼 수 있습니다. 다시 말해, AAL, PPL 모두 Task Scheduler 와 Resource Manager 를 사용한다는 말입니다.

 Concurrency Runtime 이 아닌 다른 프레임워크에서도 하위 레벨보다 상위 레벨 컴포넌트가 사용 용이성과 안정성이 높은 것처럼 Concurrency Runtime 에서도 마찬가지입니다.

 Concurrency Runtime 개발자들은 비 동기 작업들을 하기 위해서는 AAL, 단위 작업의 병렬 처리를 하기 위해서는 PPL 을 사용하기를 권하고, 좀 더 특별한 최적화나 하위 레벨 작업이 필요한 경우에만 직접 Task Scheduler 를 사용하기를 권하고 있습니다.

 즉, AAL 은 Concurrency Runtime 의 비 동기 작업을 위한 인터페이스라고 볼 수 있습니다.( PPL 은 병렬 처리를 위한 인터페이스라고 볼 수 있습니다. )

 

비 동기 작업

 비 동기 작업이란 작업이 끝날 때까지 기다리지 않는다는 말입니다. 즉, 어떤 함수가 있을 때, 그 함수는 바로 반환되어야 합니다. 바로 반환되면 호출한 스레드는 바로 다른 작업을 수행할 수 있습니다. 이 때, 해당 함수의 작업은 호출한 스레드가 아니라 다른 작업 스레드에서 수행되고, 작업이 완료되면 호출한 스레드에게 통지하거나, 콜백( call back ) 함수를 호출합니다.

 이러한 처리 방식을 비 동기 처리 방식이라고 합니다. AAL 은 이런 비 동기 작업을 용이하게 해주는 라이브러리입니다.

 

기능

 AAL 은 크게 두 가지 특징을 가지고 있습니다. 하나는 actor-based 프로그래밍 모델이고, 다른 하나는 message passing 프로그래밍 모델입니다.

Agent

 Agent 는 AAL 의 기능 중 하나인 actor-based 프로그래밍 모델의 actor 를 나타내는 개념입니다. 인공 지능 등과 같은 다른 분야에서 사용하는 개념과 마찬가지로 어떤 임무를 수행하는, 즉 어떤 역할을 하는 객체를 일컫습니다.

 예를 들어, 스마트 폰이 만들어 지려면 케이스( case ) 생산, 하드웨어 생산, 케이스와 하드웨어 조립, OS 및 소프트웨어 설치, 테스트와 같은 공정이 필요한데, 각 공정들을 수행하는 객체들을 agent 라고 볼 수 있습니다.

Message

 Message 는 agent 들 간의 통신을 위한 메커니즘입니다. AAL 에서의 message 란 상황이나 상태를 알리기 위한 수단이 될 수도 있고, 실제 데이터를 전송하기 위한 수단이 될 수도 있습니다.

 예를 들면, 스마트 폰 공정들 사이에 케이스가 생산되었다면 생산된 케이스를 조립하는 곳으로 전달해야 합니다. 이 때, 케이스를 전달하는 수단으로 message 가 사용될 수 있습니다. 또한 케이스와 하드웨어의 조립, OS 및 소프트웨어 설치가 완료되어야지 테스트를 진행할 수 있습니다. 이런 완료 상태와 같은 작업의 상태를 알리기 위해서 message 가 사용될 수 있습니다.

 

예제

 위에 언급한 스마트 폰 생산 과정을 AAL 을 이용하여 구현해보았습니다. 예제가 비교적 긴 편이지만 최대한 이해하기 쉽게 직관적인 코드를 작성했습니다. AAL 을 중점적으로 소개하기 위해 디자인이나 테크닉은 무시하고 작성하였습니다.

 전체적인 흐름을 이해하는 데에는 어려움이 없을 것 같으나 사용된 함수들이 어떤 역할을 하는지 궁금할 것입니다.

시나리오

1.  스마트 폰 케이스 생산자와 하드웨어 생산자가 각각 케이스와 하드웨어를 부품으로 생산한다.
2.  생산된 부품을 조립하는 객체에게 전달하면 조립하는 객체가 조립하게 된다.
3.  조립된 스마트 폰은 소프트웨어 설치 객체에게 전달되고, 그 객체는 소프트웨어를 설치한다.
4.  소프트웨어가 설치된 스마트 폰은 테스터에게 전달되고, 테스터는 테스트에 성공한 스마트 폰을 제품 컨테이너에 저장한다.
5.  제품 컨테이너의 제품들을 출력하고 종료한다.

코드

// 스마트폰 생산 예제 코드
#include <iostream>
#include <agents.h>
#include <ppl.h>

using namespace std;
using namespace Concurrency;

// 케이스 클래스
class Case
{
};

// 하드웨어 클래스
class Hardware
{
};

// 소프트웨어 클래스
class Software
{	
};

// 스마트폰 클래스
class SmartPhone
{
public:
	int			uid;

	Case*		pCase;
	Hardware*	pHardware;
	Software*	pSoftware;

	~SmartPhone()
	{
		if( 0 != this->pCase )
		{
			delete this->pCase;
			this->pCase = 0;
		}

		if( 0 != this->pHardware )
		{
			delete this->pHardware;
			this->pCase = 0;
		}

		if( 0 != this->pSoftware )
		{
			delete this->pSoftware;
			this->pSoftware = 0;
		}		
	}

	SmartPhone( int _uid, Case* _pCase = 0, Hardware* _pHardware = 0, Software* _pSoftware = 0 )
		: uid( _uid )
		, pCase( _pCase )
		, pHardware( _pHardware )
		, pSoftware( 0 )
	{
		if( 0 != _pSoftware )
			this->pSoftware = new Software( *_pSoftware );		
	}		

	void SetSoftware( Software* _pSoftware )
	{
		if( 0 != this->pSoftware )
			delete this->pSoftware;

		this->pSoftware = new Software( *_pSoftware );
	}
};

// 메시지 버퍼 typedef
typedef unbounded_buffer< Case* >		CaseBuffer;
typedef unbounded_buffer< Hardware* >	HardwareBuffer;
typedef unbounded_buffer< SmartPhone* >	SmartPhoneBuffer;

typedef vector< SmartPhone* >			SmartPhoneVector;

// 케이스 생산자 agent
class CaseProducer
	: public agent
{
private:
	unsigned int	caseCountToCreate;
	CaseBuffer&		caseBuffer;	

protected:
	void run()
	{
		// 필요한 개수 만큼 케이스를 생산하고 케이스 버퍼로 보낸다.
		for( unsigned int i = 0; i < this->caseCountToCreate; ++i )
		{
			send( this->caseBuffer, new Case );
			wcout << i << L": created a case." << endl;
		}

		// 모두 보냈으면 생산을 완료했다는 메시지로 널( 0 ) 포인터를 보낸다.
		send( this->caseBuffer, static_cast< Case* >( 0 ) );

		done();
	}

public:	
	CaseProducer( unsigned int _caseCountToCreate, CaseBuffer& _caseBuffer )
		: caseBuffer( _caseBuffer )
		, caseCountToCreate( _caseCountToCreate ) { }	
};

// 하드웨어 생산자 agent
class HardwareProducer
	: public agent
{	
private:
	unsigned int		hardwareCountToCreate;
	HardwareBuffer&		hardwareBuffer;

protected:
	void run()
	{
		// 필요한 개수 만큼 하드웨어를 생산하고 하드웨어 버퍼로 보낸다.
		for( unsigned int i = 0; i < this->hardwareCountToCreate; ++i )
		{
			send( this->hardwareBuffer, new Hardware );
			wcout << i << L": created a hardware." << endl;
		}

		// 모두 보냈으면 생산을 완료했다는 메시지로 널( 0 ) 포인터를 보낸다.
		send( this->hardwareBuffer, static_cast< Hardware* >( 0 ) );

		done();		
	}

public:
	HardwareProducer( unsigned int _hardwareCountToCreate, HardwareBuffer& _hardwareBuffer )
		: hardwareCountToCreate( _hardwareCountToCreate )
		, hardwareBuffer( _hardwareBuffer ) { }
};

// 부품( 케이스와 하드웨어)을 조립하는 agent
class Assembler
	: public agent
{
private:
	CaseBuffer&			caseBuffer;
	HardwareBuffer&		hardwareBuffer;

	SmartPhoneBuffer&	incompletedSmartPhoneBuffer;

protected:
	void run()
	{
		unsigned int loopCount = 0;

		// 버퍼에 쌓인 부품( 케이스와 하드웨어 )을 꺼내 조립하여 스마트폰을 만든다.
		while( true )
		{
			Case* pCase = receive( this->caseBuffer );
			Hardware* pHardware = receive( this->hardwareBuffer );

			// 더 이상 조립할 부품( 케이스 또는 하드웨어 )들이 없으면, 
			// 스마트폰 생산이 완료되었음을 알리는 메시지로 널( 0 ) 포인터를 보낸다.
			if( 0 == pCase || 0 == pHardware )
			{
				// 남은 케이스를 파괴한다.
				if( 0 != pCase )
				{
					while( true )
					{
						Case* pGarbageCase = receive( this->caseBuffer );

						if( 0 == pGarbageCase )
							break;

						delete pGarbageCase;
					}					
				}

				// 남은 하드웨어를 파괴한다.
				if( 0 != pHardware )
				{
					while( true )
					{
						Hardware* pGarbageHardware = receive( this->hardwareBuffer );

						if( 0 == pGarbageHardware )
							break;

						delete pGarbageHardware;
					}
				}

				send( this->incompletedSmartPhoneBuffer, static_cast< SmartPhone* >( 0 ) );
				break;
			}

			send( this->incompletedSmartPhoneBuffer,
				new SmartPhone( loopCount + 1, pCase, pHardware ) );

			wcout << loopCount << L": created a smart phone." << endl;

			++loopCount;
		}
		
		done();
	}

public:
	Assembler( CaseBuffer& _caseBuffer, HardwareBuffer& _hardwareBuffer, 
		SmartPhoneBuffer& _incompletedSmartPhoneBuffer )
		: caseBuffer( _caseBuffer )
		, hardwareBuffer( _hardwareBuffer )
		, incompletedSmartPhoneBuffer( _incompletedSmartPhoneBuffer ) { }	
};

// 소프트웨어 설치 agent
class SoftwareInstaller
	: public agent
{	
private:
	Software&			software;	

	SmartPhoneBuffer&	incompletedSmartPhoneBuffer;
	SmartPhoneBuffer&	completedSmartPhoneBuffer;

	SmartPhoneVector&	faultySmartPhoneArray;

protected:
	void run()
	{
		unsigned int loopCount = 0;

		// 조립된 스마트폰에 소프트웨어를 설치한다.
		while( true )
		{
			SmartPhone* pSmartPhone = receive( this->incompletedSmartPhoneBuffer );

			// 더 이상 소프트웨어를 설치할 조립된 스마트폰이 없으면, 설치를 중단하고
			// 소프트웨어 설치도 모두 완료되었음을 알리는 메시지로 널( 0 ) 포인터를 보낸다.
			if( 0 == pSmartPhone )
			{
				send( this->completedSmartPhoneBuffer, static_cast< SmartPhone* >( 0 ) );
				break;
			}

			wcout << loopCount;

			// 제대로 조립되었는지 판단 후, 소프트웨어를 설치한다. 
			if( 0 != pSmartPhone->pCase && 0 != pSmartPhone->pHardware )
			{
				pSmartPhone->SetSoftware( &this->software );

				send( this->completedSmartPhoneBuffer, pSmartPhone );
				wcout << L": installed the software." << endl;
			}
			else
			{
				this->faultySmartPhoneArray.push_back( pSmartPhone );
				wcout << L": failed to install the software." << endl;
			}

			++loopCount;
		}		

		done();
	}

public:
	SoftwareInstaller( Software& _software, SmartPhoneBuffer& _incompletedSmartPhoneBuffer,
		SmartPhoneBuffer& _completedSmartPhoneBuffer, SmartPhoneVector& _faultySmartPhoneArray )
		: software( _software )
		, incompletedSmartPhoneBuffer( _incompletedSmartPhoneBuffer )
		, completedSmartPhoneBuffer( _completedSmartPhoneBuffer )
		, faultySmartPhoneArray( _faultySmartPhoneArray ) { }
};

// 테스트하는 agent
class Tester
	: public agent
{
private:
	SmartPhoneBuffer&	completedSmartPhoneBuffer;

	SmartPhoneVector&	productArray;
	SmartPhoneVector&	faultySmartPhoneArray;

protected:
	void run()
	{
		unsigned int loopCount = 0;

		// 조립된 스마트폰에 소프트웨어 설치가 완료된 스마트폰을 테스트한다.
		while( true )
		{
			SmartPhone* pSmartPhone = receive( this->completedSmartPhoneBuffer );

			// 더 이상 테스트할 스마트폰이 없으면 중단한다.
			if( 0 == pSmartPhone )				
				break;

			wcout << loopCount;

			if( this->Test( pSmartPhone ) )
			{
				this->productArray.push_back( pSmartPhone );
				wcout << L": succeeded in testing." << endl;
			}
			else
			{
				this->faultySmartPhoneArray.push_back( pSmartPhone );
				wcout << L": failed to test." << endl;
			}

			++loopCount;
		}
		
		done();
	}

public:
	Tester( SmartPhoneBuffer& _completedSmartPhoneBuffer,
		SmartPhoneVector& _productArray, SmartPhoneVector& _faultySmartPhoneArray )
		: completedSmartPhoneBuffer( _completedSmartPhoneBuffer )
		, productArray( _productArray )
		, faultySmartPhoneArray( _faultySmartPhoneArray ) { }

	bool Test( SmartPhone* _pSmartPhone )
	{
		return ( 0 != _pSmartPhone->pCase && 0 != _pSmartPhone->pHardware
			&& 0 != _pSmartPhone->pSoftware );		
	}	
};

int main()
{
	// 케이스 생산자 agent 생성.
	int caseCountToCreate = 10;
	CaseBuffer caseBuffer;
	CaseProducer caseProducer( caseCountToCreate, caseBuffer );

	// 하드웨어 생산자 agent 생성.
	int hardwareCountToCreate = 10;
	HardwareBuffer hardwareBuffer;
	HardwareProducer hardwareProducer( hardwareCountToCreate, hardwareBuffer );

	// 부품( 케이스와 하드웨어 )을 조립하는 agent 생성.
	SmartPhoneBuffer	incompletedSmartPhoneBuffer;
	Assembler assembler( caseBuffer, hardwareBuffer, incompletedSmartPhoneBuffer );	
	
	// 소프트웨어 설치 agent 생성.
	SmartPhoneVector	faultySmartPhoneArray;

	SmartPhoneBuffer	completedSmartPhoneBuffer;
	SmartPhoneBuffer	faultySmartPhoneBuffer;
	Software android;
	SoftwareInstaller softwareInstaller( android, incompletedSmartPhoneBuffer,
		completedSmartPhoneBuffer, faultySmartPhoneArray );

	// 테스트하는 agent 생성.
	SmartPhoneVector	productArray;

	SmartPhoneBuffer	productBuffer;	
	Tester tester( completedSmartPhoneBuffer, productArray, faultySmartPhoneArray );

	// 모든 생성된 agent 작업 시작.
	caseProducer.start();
	hardwareProducer.start();
	assembler.start();
	softwareInstaller.start();
	tester.start();

	// 모든 agent 의 작업이 끝날 때까지 대기.
	agent* watingAgents[] = { &caseProducer, &hardwareProducer, &assembler,
		&softwareInstaller, &tester };

	agent::wait_for_all( sizeof( watingAgents ) / sizeof( agent* ), watingAgents );
	agent::wait( &caseProducer );
	agent::wait( &hardwareProducer );
	agent::wait( &assembler );
	agent::wait( &softwareInstaller );
	agent::wait( &tester );	

	// 완성된 제품 출력.
	wcout << L"completed products: " << endl;

	parallel_for_each( productArray.begin(), productArray.end(),
		[] ( SmartPhone* _pSmartPhone )
	{
		wcout << L"product uid: " << _pSmartPhone->uid << endl;
	});

	// 자원 정리 - 완제품.
	parallel_for_each( productArray.begin(), productArray.end(),
		[] ( SmartPhone* _pSmartPhone )
	{
		if( 0 != _pSmartPhone )
			delete _pSmartPhone;
	});	

	// 자원 정리 - 불량품.
	parallel_for_each( faultySmartPhoneArray.begin(), faultySmartPhoneArray.end(),
		[] ( SmartPhone* _pSmartPhone )
	{
		if( 0 != _pSmartPhone )
			delete _pSmartPhone;
	});
}

[ 코드1. 예제 코드 ]

실행 결과

 모든 agent 가 수행하는 작업이 비 동기적으로 호출되었고 결과를 기다립니다. 비 동기적으로 호출된 agent 의 작업들은 각각 독립적인 스레드에서 동시에 수행되며, 작업을 수행하는데 데이터가 필요하다면 메시지에 의해 필요한 데이터가 도착할 때까지 동기화되어 수행됩니다.

 wcout 객체는 동기화되지 않기 때문에 작업의 넘버링이 엉켜있는데 실제로 세어보면 정확히 맞아 떨어집니다.

메모리 누수

코드에 명시적인 메모리 누수가 없어도 Concurrency Runtime 에 의한 메모리 누수가 발견됩니다. 이것은 개발팀에서도 버그라고 인정하고 있습니다. 하지만 이번 2010 버전에는 수정되지 않을 것이고, 다음 버전인 서비스팩에 수정되어 포함될 것이라고 합니다.

참고: http://vsts2010.net/263

AAL 의 편리함

 위의 예제가 보여주다시피 AAL 을 사용하면 정말 간단하게 여러 객체의 작업을 비 동기적으로 동시에 수행시킬 수 있습니다.

만약 직접 Win32 API 를 사용하여 이를 구현하려 한다면 각 데이터를 보관하는 컨테이너에 대한 동기화 등과 같은 복잡한 메카니즘을 이벤트 등과 같은 동기화 객체를 사용하여 직접 구현해야 합니다.

물론, 결국은 OS의 커널( kernel ) 객체를 사용하여 구현되겠지만, 빠른 생산성의 이익과 동기화로 인한 스트레스로 인해 피폐해져 가는 인간성을 지킬 수 있다는 측면에서는 굉장히 편리한 도구임에 틀림없습니다.

 

마치는 글

 이번 글은 AAL 에 대한 개념과 어떻게 동작하는지 간단한 소개입니다. 다음 글에서 구현에 필요한 함수들과 사용법들을 이야기해 보겠습니다.

 

참고

• 그림1. Concurrency Runtime Architecture - http://i.msdn.microsoft.com/dynimg/IC315446.png

6월 1일, 국내 최고 웹 전문가가 소개하는 ReMIX 10 - Mobile. Web. Cloud NOW 그 어떤 산업보다 빠르게 변화하고 새로운 기술에 가장 민감하게 반응하는 웹과 UX. 해마다 웹 시장에 대한 통찰과 함께 웹 비즈니스를 위한 새로운 기술을 소개해 드렸던 ReMIX 10이 현재의 시장을 좌우하는 가장 중요한 조류 Mobile. Web. Cloud를 짚어드립니다. 국내 최고의 전문가들이 총출동하여 선보이는 윈도우폰 7, 실버라이트 4, 윈도우 애저. 모든 기술의 근간이 되는 Visual Studio 2010과 Expression 4 신제품 발표. 웹 기술을 선도하는 기업들의 개발과 디자인 실제 사례를 직접 만날 수 있는 국내 최고의 웹 컨퍼런스 ReMIX 10 - Mobile. Web. Cloud NOW 6월1일, 여러분의 기대를 넘어서는 ReMIX 10이 다가옵니다!

키노트 세션- Mobile, Web, Cloud NOW 모바일과 클라우드에 의해 급변하는 웹. 마이크로소프트는 이 변화의 시기에 무슨 생각을 하고 있을까? 국내 굴지의 기업들과 파트너들의 다양한 사례 및 데모로 알아 보는 웹의 미래 전략과 방향성. 윈도우 폰 7, 실버라이트 4, 비주얼스튜디오 2010, 익스프레션 4는 그 시작에 불과합니다. 한눈에 살 펴보는 윈도우 폰 7 앱 개발 - 디자인부터 개발까지 이 세션에서는 전 세계의 1인 창조 기업 또는 개인 개발자들을 위해 처음으로 윈도우 폰 7 애플리케이션 개발을 비주얼 스튜디오 2010과 익스프레션 블랜드를 이용하여 어떻게 동작하는지 직접 데모를 보여드립니다. 혁신적인 프로그램을 만드는 .NET 4 와 비주얼 스튜디오 2010 NET 4와 비주얼 스튜디오 2010은 개발자 여러분들의 개발 편의성과 효율성을 제공해 드리며, 다양한 플랫폼과 고성능, 고품질 애플리케이션 개발을 하실 수 있도록 완전히 새로운 모습으로 태어났습니다. 이번 세션에서는 .NET 4와 비주얼 스튜디오 2010이 얼마나 상호 작용을 통해 개발자를 도울 수 있는지 보도록 하겠습니다.

> 좌석이 한정되어 있으니, 반드시 사전 등록해 주시기 바랍니다. > 본 행사는 점심식사가 제공되지 않습니다. > 설문지를 작성해 주신 분들께는 소정의 기념품을 드리며, 행사 종료 후 추첨을 통해 푸짐한 경품을 드립니다.

Client Object Model에 대해서 다시 한번 정리를 해보도록 하겠습니다.

 

SharePoint 개체를 액세스 하기 위해서는 Microsoft.SharePoint.dll 이 있어야 하는데 원격 클라이언트에서는 Microsoft.SharePoint.dll 어셈블리를 접근하기 곤란합니다. SharePoint 2010에서는 Client Object Model을 제공해서 원격 클라이언트에서 손쉽게 SharePoint 데이터를 액세스할 수 있습니다.

 

아래 그림은 Client Object Model을 설명하면서 언급하는 그림인데 저는 먼저 코드를 나열하고 살펴봅니다.

Client Object Model을 사용할 수 있는 주된 이유는 아래 그림의 SharePoint 서버쪽의 Client.svc 때문입니다. Client.svc가 서버 개체 모델을 액세스해서 JSON 포맷으로 결과를 반환해주게 되며 클라이언트에서는 Proxy를 통해 손쉽게 액세스하게 됩니다.

 

 

앞에서 한번 살펴보았던 표를 다시 한번 정리 합니다.

SP 이름만 제외하면 서버, 클라이언트 개체 모델이 유사하다는 것을 기억 하시죠?

Server (Microsoft .SharePoint)	.NET Managed (Microsoft.SharePoint .Client)	Silverlight (Microsoft.SharePoint .Client.Silverlight)	JavaScript (SP.js)
SPContext	ClientContext	ClientContext	ClientContext
SPSite	Site	Site	Site
SPWeb	Web	Web	Web
SPList	List	List	List
SPListItem	ListItem	ListItem	ListItem
SPField	Field	Field	Field

 

.NET Managed Client OM

-       Microsoft.SharePoint.Client.dll

-       Microsoft.SharePoint.Client.Runtime.dll

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

 

Silverlight Client OM

-       Microsoft.SharePoint.Client.Silverlight.dll

-       Microsoft.SharePoint.Client.Silverlight.Runtime.dll

(C:\Program Files\Common Files\Microsoft Shared\
Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin)

 

JavaScript Client OM

<SharePoint:ScriptLink ID="ScriptLink1" Name="SP.js" runat="server" OnDemand="true"

    Localizable="false" />

 

 

아래 주소를 참고하시면 성능 향상 등의 더 높은 수준의 코드를 살펴보실 수 있습니다.

 

http://msdn.microsoft.com/en-us/library/ee857094(office.14).aspx

- 개념!!

군 생활을 하다 보면, 개념 없는 사람들을 많이 보게 됩니다. 가끔은 '내가 평생 이런 놈을 다시 볼 수 있을까?'싶은 사람도 보게되죠. 그리고 인간관계란 과연 무엇인지 원점에서 다시 생각해 보게 됩니다. 개념 없는 사람들도 사회에서 담당하는 역할이 있는 셈이죠. 오늘은 병렬 프로그래밍에 필요한 개념들을 같이 채워볼까 합니다. 개념 충만한 사람들은 훠이훠이~ 절로 가시고(저는 종교의 다양성을 존중합니당. 교회로 가실 분은 교회로..), 개념 없는 사람들만 저랑 같이 개념을 채워 보시져. 훗.


- 기본 개념!!!

스레드(Thread)

스레드는 다른 순차적 명령 집합(sequence of instructions)과 동시적으로 실행 가능한 순차적 명령 집합을 이야기 합니다. 예를 들면, 뭔가 작업을 처리하는 스레드가 있고, 그 작업의 현황을 화면에 표시하는 스레드가 있는 것 처럼 말이죠. 두 스레드는 서로 다른 순차적 명령 집합을 가지며, 동시적으로 실행 가능하죠. 그리고 두 개 이상의 스레드를 동시적으로 실행하는 것을 멀티스레딩(multithreading)이라고 합니다. 흔히 이야기 하는 동시성이나 병렬성도 최대한 효율적으로 스레드를 여러개 사용하는 것이므로, 멀티스레드의 범주에 들어간다고 할 수 있겠습니다. 운영체제는 이런 멀티 스레드를 동시적으로 처리하는 것 처럼 보여주기 위해서 시간 쪼개기(time slicing)이라는 기법을 활용합니다. 즉, 사람이 눈치채지 못할 정도로 빠른 시간만큼 한번에 하나씩 스레드를 처리하는 것이죠. 단순하게 생각해서, 음악을 들으면서 비주얼 스튜디오로 코딩을 한다면, 사람이 눈치채지 못할 정도의 속도로, 예를 들면 1/24초 정도의 속도로 한번은 음악재생, 한번은 비주얼 스튜디오, 또 한번은 음악 재생, 또 한번은 비주얼 스튜디오 이런식으로 번갈아 가면서 처리하는 것이죠. 이걸 문맥 교환(context switching)이라고 합니다. <그림1>을 보시죠.

<그림1>본격 OS 스케쥴링 그림.jpg

<그림1>에서 나온 것 처럼, 사용자가 눈치채지 못 할만큼의 속도로 두 작업을 번갈아 가면서 CPU가 처리하도록 OS가 스케쥴을 조절하는 것이죠. 그런데 만약, 스레드가 너무 많아서 제대로 CPU를 점거하지도 못하고, 작업을 계속해서 교체하게 되면 어떻게 될까요? 실제로 CPU가 작업을 처리하는 시간보다, 문맥 교환에 더 많은 시간이 들어가게 되므로, 음악이 벅벅 끊기는 등의 지름유발상황이 생기겠죠. 그럼, 시간 쪼개기를 한번 시뮬레이트 해 볼까영? 어헣.

using System; using System.Threading.Tasks; namespace Exam2 {     class Program     {         static void Main(string[] args)         {             const int max = 10000;             //현재 작업중인 스레드외에 추가로 스레드를 생성             Task task = new Task(() =>                 {                     for (int count = 0; count < max; count++)                     {                         Console.Write("|");                     }                 });             //추가 스레드 시작             task.Start();             //현재 작업중인 스레드에서도 반복문 시작             for (int count = 0; count < max; count++)             {                 Console.Write("-");             }             //혹시 현재 스레드가 빨리 끝나더라도,             //추가 스레드가 끝날 때 까지 기다리기.                        task.Wait();         }     } }

<코드1>아주 단순한 코드

<코드1>은 아주 단순한 코드입니다. 콘솔 어플리케이션의 실행을 담당하는 스레드 외에, 추가로 스레드를 하나 더 생성해서, 두 스레드에서 똑같은 반복문을 돌면서 서로 다른 문자를 출력하게 하는 거죠. 결과를 볼까요?

-|---||||||||||||||||------|||||||||||||||---------------|||||||||||||-----------||||||--------------|||||||||||||--------------|||||||||||||------------||||||||--------------||||||||||||----------||||||||||||||---------|||||||||||||--------|||||||||||||||--------------|||||||||||||||-------------||||||||||||-||||||||||-----------------|||||||||||||||-------------||||||||||||||--|||||||||||||-------|||||||---------------|||||||||||||||----------||||||||||||||---------|||||||||-----------------||||||||||||||-------------|||||||||||||-------------||||||||||-----------------|||||||||||||------------|||||||||||||-----------||||||||------|||||||||||||--------|||||||||||||||-----||||||||||||||-------------||||||||||||----------------|||||||||||||---------------|||||--------------|||||||||||||----||||||||||||||||--------------|||||||||||||||---------||||||||||||-----------|||---------------||||||||||||||||----------------||||||-------------|||||||||----|||||||||||||||||-------------||||||||||||||-||||||||||||||-------------||||||||-------|||||||||||||||--------|--|||---------|||||||||||||--------|||||||||||---|||||||||||||||----------------|||||||||||||||--------------||||----------------------------------------------------------------------------------------------- 계속하려면 아무 키나 누르십시오 . . .

<결과1>평범한 결과

서로 다른 문자가 출력되는 곳이 바로, 시간 쪼개기로 인한 문맥 교환이 일어나는 곳입니다. 정해진 시간만큼 한 스레드가 CPU를 점거하고 작업을 하는 것이죠. 그러면, 약간 방해를 해볼까요? 코드를 다음과 같이 약간 수정해봅니다.

Console.ReadLine(); //추가 스레드 시작 task.Start();

<코드2>수정된 아주 평범한 코드

그리고 이 프로그램이 사용자의 입력을 기다리는 동안, 다음과 같이 프로세스의 우선순위를 낮춰버립니다.

<그림2>프로세스 우선순위 낮추기 ㅋ

그리고 한번 실행해 볼까요? 프로세스의 우선순위가 낮아지면, 실행중인 작업이 우선순위가 높은 다른 프로세스에게 방해를 받을 가능성이 높아지는 거죠.

---------|||||||----||||||||||||||||-----||||||||||||--------||||||||||||||------------|||||||||----------------||||||||||||||------------||||||||||||||-------------|||||||||||----------------|||||||||||||-----------||||||||||||||-------------||||||||||||--------||||||||||||||------------|||||||||||||||-------------|||||||||||||------||||||||||||||-------------||||||||||||||--------------|||||||||||-----------||||---------------|||||||||||||-------------||||||||||||||-------|||||||||||||----|||||||||||||--------------|||||||||||||||-------------|||||||||||||-|||||||||||---------------||||-------------|||||||||||||-------------|||||||||||||---------|----------------|||||||||||||-------------||||||||||||||-----------||||||||||||---------------|||||--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 계속하려면 아무 키나 누르십시오 . . .

<결과2>낮은 우선순위 결과

그런데, <결과2>를 보니, 얼마나 방해를 받은 건지 솔직히 잘 모르겠네요.('-'가 마지막에 막 출력된 건, '|'를 출력하는 스레드가 빨리 작업을 끝내서 입니당) 제 컴이 쿼드에 2.7GHz짜리인데, 아마도 이정도로는 방해가 안되는 거 같습니다. 그래서! 비주얼 스튜디오 2010 20개랑, 음악을 틀고, 바이러스 검사를 돌리고, 인터넷 익스플로러 8도 창을 7개정도 띄워놓고 실험을 해봤습니다.

-||||||||||||||||-------------|---------------|--------------||||||||||----------||||||||||||||-----------||||||||||||--------------|||||||||||---------||||||||-|||||||----|||||||||------------|||||||||||||-------------|||-----------||||||||---------------||||||||||||||-------------||||||-------------||||||||||--------||||||||||||||----|||||||||||||||--------------||||||||||||-----------||||||||||----------------|||||||||||----------|------------||-|||||||||------||-------|||--------------|||||||||||||------------|||||||||||||-------------|||||||||||----|||||||||||-----||||||||||||||---------------||||||||||||||------------|||||||||----------------||||||||||||--------|||||||||||||-------------|||||||||-------|||------------|||||-----|||||||------||||||||||||||||---------------------||||||------|||||||||||||||-------------||||||||||||||-------------||||||||||||--------||||||||||||||||-------------||||||||||--------------|||||||||-------||||------|----||||||-----||||||||||||||-------------|||||||||------------|||||||||||-------||||||||||||||--------------||||||||||||||--------------||||||||||--------|||| |--------------||||||||||||||||-----------|||||||||||||--|||||||||||------||||||||----------------||----||||||||||||||-----|||||||||||||||||||||||||||||||||||||| 계속하려면 아무 키나 누르십시오 . . .

<결과3>갖가지 태클을 가한 결과

<결과3>을 보시면, 어느 정도 패턴이 불안정 해진 걸 보실 수 있습니다. 제대로 처리도 못하고, '|'이거 딱 한개 출력하고 문맥 교환이 일어난 부분도 꽤 보이네요.


원자성(Atomicity)

원자성은 뭘까요? 원자성을 만족하는 조건을 보지요. 아래 조건 중에서 하나를 만족하면 원자성을 만족하는 것입니다.

1. 작업을 처리하기 위한 명령어 집합은 다른 작업이 끼어들기 전에 반드시 완료되어야 한다. 2. 작업을 처리 중인 시스템의 상태는, 작업을 처리하기 전의 시스템의 상태로 돌아갈 수 있어야 한다. 즉, 아무 작업도 처리되지 않은 시스템의 상태로 돌아갈 수 있어야 한다.

예를 들면, 은행 계좌에서 돈을 송금하는 걸 생각해보면요. 돈을 송금하기위한 몇가지 단계가 있습니다. 일단 계좌에 돈이 있는지 확인하고, 보낼 계좌가 존재하는지 확인하고, 그리고 돈을 실제로 송금하는 것이죠. 이렇게 송금을 위한 각 단계를 밟는 와중에, 돈을 인출한다던가 하는 작업이 끼어들면 안되겠죠. 그리고 송금 절차가 완료되기 전에는 계좌에 아무런 변화가 없어야 하는 거죠.

C#에서 num++같은 연산을 보면, num의 값을 가져오고, num의 값을 1 증가시키고, num에 증가된 값을 넣는 절차를 밟는데요. ++연산자는 원자성을 만족하지 못합니다. 그래서 num에 증가된 새 값을 넣기 전에, 다른 스레드가 원래 값을 변경 시켜버린다던가 하는 일이 벌어질 수 있죠.


데드락(Deadlock)

데드락은 죽음을 잠근다는 뜻이므로, 죽지 않는다는 뜻입니다. 네, 저를 죽이려고 달려드는 사람들의 모습이 보이네요. 모두들 잠깐만 진정하시고....-_- 이건 서로 볼을 꼬집고서, '니가 먼저 안놓으면, 나도 안놓을 꺼임'하고 외치고 있는 꼬마들을 생각하시면 됩니다. 꼬맹이들은 괜한데서 자존심을 세우죠. 그래서 먼저 놓으면 지는거라고 생각해서 안 놓습니다. 그래서 서로 계속해서 볼을 꼬집고 질질 짜게 되는 거죠. ㅋㅋㅋ

한 스레드는 A라는 자원을 점거하고, B를 가지고 와야 A를 놓아줍니다. 그리고 또 다른 스레드는 B라는 자원을 점거하고, A를 가져와야 B를 놓아준다고 해보죠. 그러면 이 스레드들은 서로 상대방이 가진 자원을 하염없이 기다리는 상황이 됩니다. 죽을 때까지 그 상태로 기다리겠죠. 그래서 이건 데드락입니다. 어헣.


- 정리하면서

위에서 설명드린 원자성이나 데드락은 여러개의 스레드에서 어떤 순서로 명령어를 실행하느냐에 따라서 복잡하게 발생합니당. 이런 프로그램을 짜려면 머리 빠지겠죠. 아이 무셔워라. 그래서 조심해야 하는 것이고, 이런 실수를 최대한 줄여주는 도구가 있어야 하는 것이죠!!

이게 왠 운영체제 수업이냐 하고 반감을 가지시는 분덜도 있으시리라 생각이 됩니다. 모.. 복습했다 생각하시고 어헣. 좋은게 좋은거니깐.. 어헣.


- 참고자료

1. http://www.cafeaulait.org/course/week11/03.html
2. Essential C# 4.0, Mark Michaelis, Addison Wesley

해외에서 더 호평을 받던 VSGesture 를 Visual Studio 2010 버전으로 다시 만들어 공개하였습니다.

VSGesture 는 VS2010 에서 마우스로 창을 닫거나, 빌드, 디버깅 명령을 내릴 수 있는 추가 기능이랍니다.
아래의 Visual Studio Gallery 사이트에 가시면 별점 많이 주세요^^

VSGesture v2.0 for VS2010 is now available for download.
http://blog.powerumc.kr/305
http://visualstudiogallery.msdn.microsoft.com/en-us/e03c91ff-e20d-4dcc-822b-172a68c40f5b

VSGesture can execute command via mouse gestures within Visual Studio2010.
If you have any feedback, please send me an email to powerumc at gmail.com.

Visual Studio 2005, 2008 version : Here

   

   

- 끝은 또 다른 시작일 뿐.

인생에서는 항상 뭔가가 끝나면 뭔가가 시작되기 마련입니다. 직장을 그만두면, 직장인은 끝나지만, 백수가 시작되죠. 직장을 구하면, 백수가 끝나고 직장인을 시작하는 것이구요. 길고 길었으며, 별로 인기 없었던 Welcome to dynamic C#이 끝나고, 앞으로도 얼마나 길고 길지 모르며, 인기도 없을 Welcome to Parallel C#이 시작됩니다. 인생에선 끝이 안나는 것도 있더군요. 허접함은 불치병이라고 들었습니다. 시한부면 좋으련만. 흥. 그래도 이 팀 블로그에서 유일하게 만나실 수 있는 허접함의 향연이니, 나름 즐겁지 않으신가요. 어헣어헣.


- 자 언제나 그렇듯이 개념정리 부터 갑시다.

언제나 그렇죠. 제 글은 언제나 그래영. 우선 개념정리부터 하고 들어갑니당. 이 시리즈가 병렬적 C#에 대한 글이니, 우선 관련된 개념부터 정리하고 들어가야죠. 어헣. 이 바닥에서 흔히 사용되지만 쫌 헷갈리는 용어가 두 개 있죠. 바로, 동시성(Concurrency)와 병렬성(Parallelism)이죠. 여러분은 이거 잘 구분되시나영? 되시면 건너 뛰시구요, 안되면? 이 글은 바로 당신과 나를 위한 글인거죠. 아.. 이건 운명적 만남. 어헣.

이 개념을 잘 정리한 글을 찾아서 인터넷을 뒤졌는데, 그 결과 나름 정리한 결과는 다음과 같습니다.

1. 첫번째 정리(동시성 vs 병렬성)

동시성과 병렬성은 같은 의미가 아니다. 만약, T1과 T2라는 두 개의 작업이 시간상 언제 어떻게 수행될지 미리 정해져있지 않다면, 그 두 작업은 동시적이라고 말할 수 있다. 즉,    T1은 T2보다 빨리 수행되고 종료될 수 있다.   T2는 T1보다 빨리 수행되고 종료될 수 있다.   T1과 T2는 같은 시간에 동시에 실행될 수 있다.(이거슨 레알 병렬성.)   T1과 T2는 교차적으로 수행될 수 있다.

2. 두번째 정리(동시적 vs 병렬적)

병렬성이라는 말은 여러개의 동일한 작업을 동시에 수행하는 것을 의미한다.(각각의 동시에 수행되는 동일한 작업들은 서로 독립적이다.) 동시성이라는 것은 여러개의 작업을 공통된 목표를 향해서 동시에 수행하는 것을 의미한다. 둘을 확실히 구분하기 힘든 것은, 동시성을 위해서 병렬성을 활용할 수 있다는 것이다. 예를 들어서 퀵소트 알고리즘을 생각해보면, 퀵소트 알고리즘의 각 분리된 단계는 병렬적으로 정렬될 수 있다. 하지만 전체 알고리즘은 동시적이다. 즉, 퀵소트 알고리즘은 동시적 이면서도(각 분할된 단계에서 나온 결과를 종합해서 하나의 공통된 목표를 추구하므로), 각 분할된 단계의 정렬은 병렬적일 수 있는 것이다. 그리고 병렬적인 각 단계의 정렬은 서로 무관하며, 서로 다른 데이터에 대해서 정렬을 하는 것이다. 그래서 좀 헷갈리긴 하겠지만, 전체 알고리즘을 병렬 퀵소트라고 부를 수도 있는 것이다.

- 넌 여전히 말이 많구나.

즉, 동시성과 병렬성은 서로 다른 개념이지만, 서로 같이 사용되는 경우가 있어서 확실히 구분하기가 애매한 경우도 있다는 말인데요. 어디 한번, 예제를 구경해보면서 이야기를 하시죠.

using System; using System.Collections.Generic; using System.IO; namespace Exam1 {     class Program     {         static void Main(string[] args)         {             List<string> files = new List<string>();             files.AddRange(Directory.GetFiles("C:\\음악", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Microsoft Visual Studio 10.0", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Microsoft Visual Studio 9.0", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Windows Mobile 6 SDK", "*", SearchOption.AllDirectories));             List<string> fileList = new List<string>();             foreach (var file in files)             {                 FileInfo fileInfo = new FileInfo(file);                 if (fileInfo.Exists)                 {                     if (fileInfo.Length >= 10000000)                     {                         fileList.Add(file);                     }                 }             }             foreach (var file in fileList)             {                 Console.WriteLine(file);             }         }     } }

<코드1> 일단 그냥 평범한 예제

<코드1>은 그냥 평범한 예제입니다. 명시해준 폴더에 있는 모든 파일을 검색해서 10메가가 넘는 파일의 목록을 만드는 프로그램이죠. 위 코드에서 왜 디렉토리를 저렇게 명시해줬냐고 물으신다면?!? 그냥 권한 때문에 접근 못하는 디렉토리가 있어서, 파일이 많은 디렉토리 위주로 골랐다고 대답해드리지요. 어헣. <코드1>을 동시성을 활용할 수는 없을까요? 만약에 동시성을 활용한다면, 어디를 동시적으로 실행 할 수 있을까요? 정답을 맞추시는 분께는 2박 3일로 하와이!!! 의 사진을 구경할 수 있는 기회를 드리겠습니다. 구글협찬이구요, PC는 개인지참입니다..... 아.. 상품대박.

foreach (var file in files) {     FileInfo fileInfo = new FileInfo(file);     if (fileInfo.Exists)     {         if (fileInfo.Length >= 10000000)         {             fileList.Add(file);         }     } }

<코드2> <코드1>에서 동시성을 활용가능한 곳!

넵, 바로 <코드2>가 동시성을 활용가능한 곳이지요. 왜냐면, 각 파일이름을 가지고 파일을 가져와서, 파일의 크기를 검사하는 각각의 작업은 서로 전혀 상관없기 때문이죠. '마재윤이조작이라니.jpg'라는 파일과 '박세식바보똥깨.avi'라는 파일에 대해서 동시에 작업이 진행된다고 해서 서로 겹치는 것도 없고, 문제가 될 것도 없습니다. 오히려, 순차적으로 수행할 때보다, 3-4개정도로 쪼개서 동시에 작업을 수행하면 훨씬 빨라지겠죠. 그래서! 여기서 병렬성을 활용하게 됩니다.

using System; using System.Collections.Generic; using System.IO; using System.Threading.Tasks; namespace Exam1 {     class Program     {         static void Main(string[] args)         {             List<string> files = new List<string>();             files.AddRange(Directory.GetFiles("C:\\음악", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Microsoft Visual Studio 10.0", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Microsoft Visual Studio 9.0", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Windows Mobile 6 SDK", "*", SearchOption.AllDirectories));             List<string> fileList = new List<string>();             Parallel.ForEach(files, (file) =>             {                 FileInfo fileInfo = new FileInfo(file);                 if (fileInfo.Exists)                 {                     if (fileInfo.Length >= 1000000)                     {                         fileList.Add(file);                     }                 }             });             foreach (var file in fileList)             {                 Console.WriteLine(file);             }         }     } }

<코드3> 병렬성! 을 활용한 버전.

<코드3>에서 굵게 처리된 부분이 바로 변경된 부분입니다. 나머지는? 똑같죠잉~~. 어헣. 굵게 처리된 부분은 .NET 4.0에서 새로 추가된 부분이며, 추후에 더 자세하게 설명드릴 기회가 있을 것 같군뇨오! 그러니깐 일단 궁금증일랑 고이접어 나빌레라~ 하시고, <코드3>을 봅시당. <코드3>에서 분명 각 리스트를 몇 부분으로 쪼개서 수행시간을 줄이려고 병렬성을 도입했지만, 각 작업의 결과는 한 개의 리스트에 추가됩니다. 즉, 10메가 넘는 파일의 목록을 만든다는 공통의 목표를 달성하기 위해서 병렬성을 사용한 것이죠. 즉, 위 코드는 병렬성을 활용한 동시적 코드입니다. 이게 위에서 열심히 동시성과 병렬성을 설명드린 내용인 거죠.


- 그래서? 얼마나 빠른기고?

자~ 그럼 얼마나 빠른건지 어디 한번 확인해봅시다.

using System; using System.Collections.Generic; using System.IO; using System.Threading.Tasks; namespace Exam1 {     class Program     {         static void Main(string[] args)         {             List<string> files = new List<string>();             files.AddRange(Directory.GetFiles("C:\\음악", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Microsoft Visual Studio 10.0", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Microsoft Visual Studio 9.0", "*", SearchOption.AllDirectories));             files.AddRange(Directory.GetFiles("C:\\Program Files (x86)\\Windows Mobile 6 SDK", "*", SearchOption.AllDirectories));             List<string> seqFileList = new List<string>();             List<string> parFileList = new List<string>();             DateTime seqStart = DateTime.Now;             //순차적 방식             foreach (var file in files)             {                 FileInfo fileInfo = new FileInfo(file);                 if (fileInfo.Exists)                 {                     if (fileInfo.Length >= 10000000)                     {                         seqFileList.Add(file);                     }                 }             }             DateTime seqEnd = DateTime.Now;             TimeSpan seqResult = seqEnd - seqStart;             DateTime parStart = DateTime.Now;             //병렬적 방식             Parallel.ForEach(files, (file) =>             {                 FileInfo fileInfo = new FileInfo(file);                 if (fileInfo.Exists)                 {                     if (fileInfo.Length >= 1000000)                     {                         parFileList.Add(file);                     }                 }             });             DateTime parEnd = DateTime.Now;             TimeSpan parResult = parEnd - parStart;             Console.WriteLine("순차적 방식 : {0}",seqResult);             Console.WriteLine("병렬적 방식 : {0}", parResult);         }     } }

<코드4> 비교를 해보자!

<코드4>처럼 순차적 방식과 병렬적 방식의 시작 시간과 끝 시간을 기록해서 두 방식에서 걸리는 시간을 측정해봤습니다. 결과능~?

순차적 방식 : 00:00:01.6270960 병렬적 방식 : 00:00:00.6230368 계속하려면 아무 키나 누르십시오 . . .

<결과1> 비교 결과.

그렇쿤뇨. 병렬적 방식이 두배 이상 빠르게 나온 걸 볼 수 있습니다. 그저 기존의 루프를 병렬 루프로 바꾼 것 뿐인데 말이죠.


- 마무리 합시다.

일단 오늘은 기본적인 개념을 명확하게 하고, 아주 간략하게 예제를 봤습니다. 일단 .NET 4.0에서 병렬 프로그래밍이 상당히 편해진 거 같긴하죠? 조금씩 더 자세히 알아보도록 하지요. 어헣.


- 참고자료

1. http://blogs.sun.com/yuanlin/entry/concurrency_vs_parallelism_concurrent_programming
2. http://my.opera.com/Vorlath/blog/2009/10/08/parallel-vs-concurrent
3. Essential C# 4.0, Mark Michaelis, Addison Wisley

- 인덱스는 왜 나오는 고냐...?

인덱스는 방대한 정보를 특정한 기준으로 잘 분류해 놔서 정보를 금방 찾을 수 있도록 해주는 고마운 장치이죠. 아무리 두꺼운 사전이 있다고 해도, 그 사전이 가나다 순이나 알파벳순으로 잘 인덱싱이 되어있지 않으면 쓸모없겠죠. C#도 그래서, 대화하기 여러운 COM과 잘 지내기 위해서 인덱스 가능한 프로퍼티를 사용하기 시작했쬬!


- 인덱스 가능한 프로퍼티가 몬데?

이름 그대로입니다. 그냥 이름 그대로 프로퍼티인데, 프로퍼티의 값을 가져올 때 인덱스로 특정 요소에 접근가능한 프로퍼티죠. 아래와 같은 모양이 인덱스로 접근하는 프로퍼티의 모습입니다.

myObject.MyIndexedProperty[index];

인덱스 가능한 프로퍼티는 내부적으로 그냥 간단한 접근자 메서드와 일반적으로 쓰이는 인덱서와 유사한 인덱서로 구성됩니다. 그냥 일반적으로 쓰는 인덱서처럼 생각할 수도 있죠. 그러면 일반적인 인덱서와의 차이점을 예제를 통해서 한번 확인해 보겠습니다. 우선 일반적인 인덱서의 예제를 보시죠.

class D {     private int[] nums = new int[] { 1, 2, 3, 4, 5, 6, 7, 8 };     public int this[int x]     {         get         {             return nums[x];         }     } } class C {     static void Main()     {         D d = new D();         for (int i = 0; i < 8; i++)         {             Console.WriteLine(d[i]);         }     } }

그리고 인덱스 가능한 프로퍼티의 사용예제입니다.

using System; using Excel = Microsoft.Office.Interop.Excel; using System.Collections.Generic; namespace OfficeInteropExam2 {     public class Account     {         public int ID { get; set; }         public double Balance { get; set; }            }     class Program     {         static void DisplayInExcel(IEnumerable<Account> accounts)         {             var excelApp = new Excel.Application();             excelApp.Visible = true;                                     excelApp.Workbooks.Add();             Excel._Worksheet workSheet = (Excel.Worksheet)excelApp.ActiveSheet;             workSheet.Cells[1, "A"] = "ID Number";             workSheet.Cells[1, "B"] = "Current Balance";             var row = 1;             foreach (var acct in accounts)             {                 row++;                 workSheet.Cells[row, "A"] = acct.ID;                 workSheet.Cells[row, "B"] = acct.Balance;             }             workSheet.Range["A1", "B3"].AutoFormat(                 Excel.XlRangeAutoFormat.xlRangeAutoFormatClassic2);         }         static void Main(string[] args)         {             var bankAccounts = new List<Account> {                 new Account {                   ID = 345678,                   Balance = 541.27                 },                 new Account {                   ID = 1230221,                   Balance = -127.44                 }             };             DisplayInExcel(bankAccounts);         }     } }

전자는 간단하게 인덱서를 사용하는 예제이구요, 두번째는 엑셀에 데이터를 표시하는 COM 프로그래밍 예제입니다. 두번째 예제에서 밑줄친 부분이 바로 인덱스 가능한 프로퍼티를 사용한 부분입니다. 겉으로 보기에는 별 차이가 없어 보이는데요. 내부적으로는 어떨까요? 리플렉터로 우선 첫번째 예제를 보겠습니다.

위에서 붉은 선으로 표시된 대로, 일반적인 인덱서 앞에는 'Item'이라는 이름이 붙습니다. 그리고 이 인덱서를 사용하는 부분의 코드는,

private static void Main() {     D d = new D();     for (int i = 0; i < 8; i++)     {         Console.WriteLine(d[i]);     } }

위와 같이 소스코드와 큰 변화가 없는 걸 볼 수 있습니다. 그러면 두번째 예제는 어떨까요? 인덱스 가능한 프로퍼티가 사용된 부분만 리플렉터로 보면,

workSheet.get_Range("A1", "B3").AutoFormat(XlRangeAutoFormat.xlRangeAutoFormatClassic2, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value);

'Range["A1", "B3"]'이라고 썼던 부분이 'get_Range'라는 메서드 호출로 바뀐걸 보실 수 있습니다. 그러면 저 get_Range를 한번 찾아볼까요?

위에서 보시듯이 'Item'이라는 표시가 없습니다. 즉 일반적인 인덱서가 아니라는 이야기죠. 그리고 접근자 메서드를 가지고 있는 걸 보실 수 있습니다. 위에서 인덱스 가능한 프로퍼티가 '접근자 메서드와 일반적으로 쓰이는 인덱서와 유사한 인덱서로 구성'된다고 이야기 한 부분이 바로 이걸 가리키는 말이었던 거죠.


- 찝찝하지만..

인덱스 가능한 프로퍼티를 그동안 추가하지 않았던 이유는 C#팀의 디자인 철학과 맞지 않아서 였다고 합니다. C#팀에서는 'C라는 타입안에 있는 P라는 프로퍼티에 접근해서 값을 가지고 온다. 그리고 그 결과값에 대해서 인덱스로 접근한다'는 시나리오가 더 옳다고 생각한다고 하네요.

하지만, 인덱스 가능한 프로퍼티를 사용하는 COM이 무척이나 많이 퍼져있다는 게 문제였다고 합니다. 그래서 이전 포스트에서 언급 해드렸던 이유와 같은 이유로 COM 프로그래밍을 지원하기 위해서 이런 기능이 추가되었다고 하네요.

비록 인덱스 가능한 프로퍼티를 사용할 수 있긴 하지만, C#에서는 인덱스 가능한 프로퍼티를 선언할 수는 없습니다. COM 라이브러리가 tlbimp라는 툴을 이용해서 만들어 지기 때문에, C#에서는 만들수 없다고 하네요. 즉 C#에서는 COM 라이브러리에 대해서만 인덱스 가능한 프로퍼티를 사용할 수 있는 것이죠.

컴파일러는 COM 타입에서 인덱스 가능한 프로퍼티로 보이는 걸 모두 임포트해둔다고 합니다. 그래서 해당 프로퍼티에 대해서는 이름을 붙인 인덱서 문법을 이용해서 사용할 수 있도록 한다고 하네요. 즉, '컴파일러는 이름을 붙인 인덱서 문법을 통해서 인덱스 가능한 프로퍼티를 사용할 수 있도록 한다'는 것이죠. 위의 예제에서 보여드렸듯이 일반적인 프로퍼티는 접근자 메서드를 통해서 바로 접근할 수 없습니다. 하지만 문법적으로는 매우 유사한 형태를 취하면서 내부적으로는 다른 일이 벌어지고 있는 것이죠.


- 오버로드 판별도 해보자.

인덱스 가능한 프로퍼티가 추가되면서 또 오버로드 판별에 변수가 생겼습니다. 아래의 예제를 가지고 설명을 해보면요,

myObject.MyIndexedProperty[index];

우선 컴파일러가 이 구문을 보게 되면, '.'왼쪽을 그 객체의 타입과 연결시킨다고 합니다. myObject의 타입이 예를 들어서 MyType이라고 하면, 그 둘을 연결시키는 것이죠. 그 다음에는 MyIndexedProperty라는 이름을 MyType에서 쭉 훑어보면서 찾습니다.

하위 호환성을 유지하기 위해서, 컴파일러가 만약 검색중에 같은 이름을 가진 평범한 프로퍼티를 보더라도 무조건 그 프로퍼티와 호출을 바인딩하게 됩니다. 하지만, MyType에서 MyIndexedProperty라는 프로퍼티를 발견했다고 해도, MyType에 인덱서가 없다면 이 프로퍼티에 호출을 바인딩하지는 않습니다.

이렇게 인덱스 가능한 프로퍼티를 제외한 일반적인 바인딩이 실패 했다면, 컴파일러는 MyType이 ComImport타입인지 확인합니다. ComImport타입이 맞다면, MyType에서 사용가능한 인덱스 가능한 프로퍼티의 리스트를 만들어서, 후보군에 대해서 오버로딩 판별을 하는데, 이때의 판별 알고리즘은 평범한 프로퍼티와 동일하게 진행됩니다. 그저 이름으로 인덱서를 취급하듯이 하는 것이죠.

그리고 인덱스 가능한 프로퍼티를 사용했다고 해서 특별한 일이 일어나는 건 아닙니다. 그저 예전버전에서 값을 가져오려면 적어야 했던 내용을 그대로 생성해주는 syntactic sugar일 뿐이기 때문이죠. 이 부분은 아래의 예제를 보시면 좀 더 명확해 집니다.

//인덱스 가능한 프로퍼티를 사용한 경우 workSheet.Range["A1", "B3"].AutoFormat(     Excel.XlRangeAutoFormat.xlRangeAutoFormatClassic2); //기존버전에서 작업해야 했던 경우 workSheet.get_Range("A1", "B3").AutoFormat(Excel.XlRangeAutoFormat.xlRangeAutoFormatClassic2,     Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,     Type.Missing);

위에서 보여드렸던 예제중에서 인덱스 가능한 프로퍼티를 사용한 코드를 리플렉터에서 보면 아래와 같았습니다.

workSheet.get_Range("A1", "B3").AutoFormat(XlRangeAutoFormat.xlRangeAutoFormatClassic2, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value);

똑같죠? 넵. syntatic sugar일 뿐이니까요. 낄낄낄.


- 마치면서

이번 포스트는 내용을 정리하면서 좀 힘들었습니다. 내공의 부족 때문인지 내용이 제대로 이해가 안됐기 때문이죠. 그런데 예제를 만들고 확인해보고 하니깐 조금씩 이해가 되더군요. 정리가 잘 된건지 모르겠습니다. 그럼 오늘은 여기까지~~!!!


- 참고자료

1. http://blogs.msdn.com/samng/archive/2009/11/03/com-interop-in-c-4-0-indexed-properties.aspx
2. http://msdn.microsoft.com/en-us/library/dd264733%28VS.100%29.aspx

앞에서 ExecuteQueryAsync 에 대한 내용과 Silverlight 웹 파트에 대한 내용을 알아보았는데 이번 블로그에서는 Silverlight Client Object Model의 또 다른 예를 살펴보도록 하겠습니다.

 

Silverlight 응용 프로그램을 생성하고 아래와 같이 디자인 합니다.

Silverlight Client Object Model 어셈블리를 참조 추가합니다.

Button의 Click 이벤트를 발생시키고 코드 보기에서 using 구문에 아래 코드를 작성합니다.

using Microsoft.SharePoint.Client;

 

생성자 위에 비동기적으로 UI 스레드를 처리하기 위해 아래 코드를 추가합니다. Dispatcher 의 BeginInvoke 에서 사용되어야 합니다. ListInfo는 LoadQuery를 통해 List 개체를 담게 됩니다.

private delegate void UpdateUIMethod();

IEnumerable<List> listInfo;   

 

아래는 목록 정보를 액세스하는 코드입니다. Button 의 Click 이벤트에 아래 코드를 통해 LoadQuery 메서드를 호출합니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

ListCollection collList = site.Lists;

context.Load(site, website => website.Title);

            listInfo = context.LoadQuery(

                collList.Include(

                    list => list.Title).Where(

                    list => list.OnQuickLaunch== true));

context.ExecuteQueryAsync(Succeeded, Failed);

빠른 실행에 표시되는 List의 Title을 담게 됩니다.

 

DisplayInfo 메서드에서 ListBox 컨트롤에 바인딩하는 코드입니다.

private void Succeeded(object sender, ClientRequestSucceededEventArgs e)

        {

            UpdateUIMethod updateUI = DisplayInfo;

            this.Dispatcher.BeginInvoke(updateUI);

        }

private void DisplayInfo()

        {

       

            this.listBox1.DisplayMemberPath = "Title";

            this.listBox1.ItemsSource = listInfo.ToList();

        }

private void Failed(object sender, ClientRequestFailedEventArgs e)

        {

            MessageBox.Show("Create Fail");

        }

 

 

 

 Xap 파일을 라이브러리에 업로드하고 Silverlight 웹 파트를 추가해서 경로를 지정합니다.

버튼을 클릭하면 빠른 실행에 있는 목록들의 Silverlight Client Object Model을 이용해서 알 수 있습니다.

SDK의 아래 주소를 참고하실 수 있습니다.

http://msdn.microsoft.com/en-us/library/ee538971(office.14).aspx

 

Silverlight Client Object Model을 알아보았고 다음 블로그에서 Javascript를 이용한 내용을 알아보도록 하겠습니다.

앞에서 .NET Managed Client Object Model에 대한 내용을 알아보았습니다. 이번 블로그에서는Client Object Model(개체 모델)을 Silverlight을 이용해서 액세스해보도록 하겠습니다.

 

SharePoint 2010에서 Media 웹 파트, Silverlight 웹 파트가 기본적으로 제공이 되고 있어 웹 파트를 만들지 않아도 되고 그냥 콘텐트를 생성하면 됩니다.

Client OM을 액세스하기 전에 Silverlight 지원되는 내용을 먼저 알아보겠습니다.

 

1. 사이트 작업의 기타 옵션을 클릭해서 여러 목록이나 라이브러리를 생성할 수 있습니다. 클릭했을 때의 화면이 Silverlight 콘텐트입니다.

2. Silverlight 미디어 웹 파트를 제공해주고 있습니다. 또한 이미지 라이브러리에 동영상을 업로드해서 바로 재생하기가 가능합니다.

3. Silverlight 웹 파트를 제공하고 있습니다.

그 외 지원되는 내용도 있지만 생략하고 바로 Silverlight을 통해 Client OM을 액세스해보도록 하겠습니다.

본격적으로 Silverlight Client Object Model을 살펴보도록 하겠습니다.

Visual Studio 2010에서 Silverlight 응용 프로그램을 생성합니다.

프로젝트이름은 SilverlightClientOMDemo으로 지정했습니다. Silverlight 응용 프로그램의 디자인은 아래와 같이 TextBox 컨트롤 2개와 Button 컨트롤 1개로 구성되어 있습니다.

Client OM을 액세스하기 위해 아래 어셈블리를 참조 추가합니다.

Microsoft.SharePoint.Client.Silverlight.dll

Microsoft.SharePoint.Client.Silverlight.Runtime.dll

 

아래 경로에 어셈블리들이 위치해 있습니다.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin

 

Using 구문에 다음과 같은 코드를 입력합니다.

using Microsoft.SharePoint.Client;

 

 

생성자 위에 비동기적으로 UI 스레드를 처리하기 위해 아래 코드를 추가합니다. Dispatcher 의 BeginInvoke 에서 사용되어야 합니다.

private delegate void UpdateUIMethod();

 

 

Client OM Button의 Click 이벤트에서 아래와 같은 코드를 작성합니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

List list = context.Web.Lists.GetByTitle("HJ");

ListItem listitem = list.AddItem(new ListItemCreationInformation());

listitem["Title"] = this.txtTitle.Text;

listitem["Body"] = this.txtBody.Text; ;

listitem.Update();      

context.ExecuteQueryAsync(Succeeded, Failed);

 

맨 마지막 라인을 제외하면 .NET Managed Client Object Model가 동일합니다.

Succeeded, Failed 에 대한 메서드는 아래와 같이 정의합니다.

private void Succeeded(object sender, ClientRequestSucceededEventArgs e)

        {

            UpdateUIMethod updateUI = DisplayInfo;

            this.Dispatcher.BeginInvoke(updateUI);

        }

private void DisplayInfo()

        {

            this.lblInfo.Text = "Success ";

        }

private void Failed(object sender, ClientRequestFailedEventArgs e)

        {

            MessageBox.Show("Create Fail");

        }

 

Silverlight 응용 프로그램을 빌드하여 이상이 없으면 xap 파일을 SharePoint 2010 사이트의 문서 라이브러리로 업로드합니다. 14 폴더의 ClientBin 폴더에 배포할 수도 있습니다.

업로드하고 나서 xap 파일을 오른쪽 클릭하여 바로 가기를 복사합니다.

HJ 공지사항을 클릭하여 페이지 편집으로 Silverlight 웹 파트를 추가합니다.

Silverlight 웹 파트 대화 상자에서 이전에 복사했던 바로 가기를 붙여넣기 합니다.

페이지 편집을 중지하고 TextBox 에 값을 입력하고 버튼을 클릭합니다.

공지사항 내용 보기를 통해서도 확인이 가능합니다.

Silverlight Client Object Model을 액세스 해보았습니다. 비동기적으로 호출하는 것(ExecuteQueryAsync)만 유념하면 .NET Managed Client Object Model과 거의 동일합니다.

다음 블로그에서는 Silverlight Client Object Model의 다른 예(LoadQuery)를 알아보도록 하겠습니다.

- 어르신과 대화하려면 어케 해야 되는거임?

간단합니다. 말씀하시는 내용을 잘 경청하고, 대꾸는 딱 필요한 만큼만 하면 되는 거죠. COM은 아마 그동안 C#이 못마땅 했을 겁니다. VB.NET은 공손하게 필요한 말만 딱 하는데, C#은 'Type.Missing'이 어쩌고 저쩌고 주저리주저리 말이 많았기 때문이죠. C#도 이제 99년도 부터 출발했다고 볼때, 11년이나 되었으니 꽤 성숙한 셈이죠. 이제 예의를 갖추기 시작한 겁니다. 낄낄낄.


- C#의 버릇없던 옛 시절.

그러면 C#얼마나 버릇이 없었는지 아주 간단한 예제를 통해 알아보시죠.

using System; using Word = Microsoft.Office.Interop.Word; namespace ConsoleApplication3 {     class Program     {         static void CreateIconInWordDoc()         {             var wordApp = new Word.Application();             wordApp.Visible = true;             object useDefaultValue = Type.Missing;             wordApp.Documents.Add(ref useDefaultValue, ref useDefaultValue,                 ref useDefaultValue, ref useDefaultValue);         }         static void Main(string[] args)         {             CreateIconInWordDoc();         }     } }

위 예제는 그냥 오피스 워드 창을 하나 띄우는 예제입니다. 그런데 평소에 오피스 COM 프로그래밍을 접해보지 못한 분이라면, 뭔가 특이한 점을 발견하셨을 겁니다. 'Type.Missing'같은 독특한 걸 object형 변수에 넣고, Add메서드에 여러번 반복해서 써넣기 때문이죠. 딱히 값을 리턴받아서 뭘 하는 것도 아닌 것 같고, Missing이라면 뭔가 없다는 것 같은데, 없는 값을 왜 저렇게 반복해서 넣어야 할까... 하는 생각이 드는 것이죠. 이제 COM이 왜 C#을 싫어했는지 아시겠나요? 말이 많았거든요.

지난 포스트에서 보셨듯이, C# 4.0은 다른 런타임과의 상호운용에 신경을 무척 많이 썼으며, 그중의 하나가 COM과의 상호운용이었습니다. C# 4.0에서는 COM과 대화할 때 좀더 말을 적게 하면서 예의를 갖춰서 대화를 하게 된 것이죠. 컴파일러가 COM 객체를 대상으로 작업하고 있다는 걸 눈치채는 순간, 컴파일러는 매개변수에 'ref'키워드를 안붙이고 메서드나, 인덱서, 프로퍼티에 넘길 수 있도록 해줍니다.

using System; using Word = Microsoft.Office.Interop.Word; namespace OfficeInteropExam2 {     class Program     {         static void CreateIconInWordDoc()         {             var wordApp = new Word.Application();             wordApp.Visible = true;             object useDefaultValue = Type.Missing;             wordApp.Documents.Add(useDefaultValue,                 useDefaultValue, useDefaultValue, useDefaultValue);         }         static void Main(string[] args)         {             CreateIconInWordDoc();         }     } }

즉 C# 4.0에서는 위 처럼 ref를 빼고 작업할 수 있도록 도와줍니다. 그리고 컴파일러가 나중에 각 매개변수 앞에 ref를 붙여서 컴파일 하는 것이죠. 일종의 syntactic sugar인 것입니다. 그런데 여기에 지난 포스트까지 설명드렸던 Named and Optional Arguments를 이용하면 아예 매개변수를 생략할 수 있습니다.

using System; using Word = Microsoft.Office.Interop.Word; namespace OfficeInteropExam2 {     class Program     {         static void CreateIconInWordDoc()         {             var wordApp = new Word.Application();             wordApp.Visible = true;             wordApp.Documents.Add();         }         static void Main(string[] args)         {             CreateIconInWordDoc();         }     } }

지난 포스트까지 설명드렸듯이 아예 매개변수를 생략하면 기본값으로 설정된 값이 넘어가게 됩니다. 그러면, Add메서드의 각 파라미터에는 기본값이 어떻게 설정되어 있을까요? Add메서드의 정의를 보면 아래와 같습니다.

Document Add(ref object Template = Type.Missing, ref object NewTemplate = Type.Missing, ref object DocumentType = Type.Missing, ref object Visible = Type.Missing);

위에서 보시듯이, 기본값은 'Type.Missing'으로 설정되어 있습니다. 즉 매개변수를 생략하고 Add메서드를 호출하면, 기본값으로 Type.Missing이 넘어가고 컴파일러는 거기에 자동으로 ref를 붙여서 호출을 완성시켜 주는 것이죠. 지금은 겨우 파라미터가 4개정도라서 감흥이 없으실지도 모르겠지만, 파라미터가 30개정도 되는 메서드들을 자주만나다보면 아마 이 기능이 너무나도 고맙게 느껴지시겠죠? ㅋㅋㅋㅋ


- 마치면서

오늘은 아주 짧게 향상된 COM 프로그래밍에 대해서 알아봤습니다. COM이 안쓰이길 바랬음에 불구하고 많이 쓰이니 어쩔 수 없이 C# 4.0에서 COM에 대한 지원이 많이 들어갔다고 하는걸 보니, 역시 기술의 생명은 벤더에게만 달린게 아니라는 생각을 해봅니다. 그럼 오늘은 여기까지 하고 다음에 또 뵙죠!


- 참고자료

1. http://blogs.msdn.com/samng/archive/2009/06/16/com-interop-in-c-4-0.aspx
2. http://msdn.microsoft.com/en-us/library/dd264733%28VS.100%29.aspx

이전 블로그에서 설명한 SharePoint 2010 데이터 기술 중에서 Client OM(개체 모델)에 대한 내용을 알아보도록 하겠습니다.

SharePoint 2010 데이터 기술에 대한 내용은 아래 주소를 참고하시기 바랍니다.

http://www.vsts2010.net/224

 

SharePoint 2010 박스 위가 아닌 원격에 떨어져 있을 경우 SharePoint 개체를 액세스하려면 웹 서비스를 통해 힘들게 해야 하지만 SharePoint 2010에서는 아주 손쉽게 접근할 수 있도록 Client OM을 제공해주고 있습니다. 생성할 수 있는 유형은 .NET, Silverlight, Javascript 를 통해 접근할 수 있습니다.

 

아래 표를 보시면 클래스와 메서드 등의 경우 서버 개체 모델과 거의 유사하게 구성되어 있습니다.

Server (Microsoft .SharePoint)	.NET Managed (Microsoft.SharePoint .Client)	Silverlight (Microsoft.SharePoint .Client.Silverlight)	JavaScript (SP.js)
SPContext	ClientContext	ClientContext	ClientContext
SPSite	Site	Site	Site
SPWeb	Web	Web	Web
SPList	List	List	List
SPListItem	ListItem	ListItem	ListItem
SPField	Field	Field	Field

 

표에서 보듯이 SP 라는 글자가 없어지고 거의 동일하게 작업이 가능합니다. 하지만 일부는 변경되어 있습니다. 웹 서비스를 통해 CAML을 처리하지 않아도 API를 통해 정말 편하게 접근이 가능합니다.

 

먼저 .NET Client OM을 알아보도록 하겠습니다. 그리고 다음 블로그에서 Silverlight, Javascript를 알아보도록 하겠습니다.

 

Visual Studio 2010을 통해 WPF 응용 프로그램을 생성합니다. 이름은 WpfClientOMDemo라고 하겠습니다.

Button 컨트롤을 디자인 영역으로 드래그하고 Click 이벤트를 생성합니다.

.NET Managed Client OM을 이용하기 위해서는 아래 어셈블리를 참조해야 합니다.

Microsoft.SharePoint.Client.dll

Microsoft.SharePoint.Client.Runtime.dll

 

경로는 아래와 같습니다.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

코드보기로 이동하여 소스 코드에 아래 using 구문을 추가합니다.

using Microsoft.SharePoint.Client;

using SP=Microsoft.SharePoint.Client;

 

InitializeComponent() 아래 부분에 다음과 같은 코드를 입력하고 프로젝트 속성에서

.NET Framework 4.0 Client Profile 을 .NET Framework 4.0으로 변경하고 실행해봅니다.

x86은 그대로 두고 진행하면 됩니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

context.Load(site);

context.ExecuteQuery();

site.Title = site.Title + " Client OM";

site.Update();

context.ExecuteQuery();

위 코드는 SP 라는 이름이 붙어있다면 서버 개체 모델과 동일하다는 것을 알 수 있습니다.

 

결과는 아래처럼 “Home Client OM”으로 변경되어 있습니다.

디자인 보기로 이동하여 ListBox 컨트롤을 드래그합니다.

코드 보기에서 위에서 작성한 코드는 주석처리하고 아래와 같은 코드를 입력합니다.

아래 코드는 목록들의 이름을 리스트박스에 추가해서 나타내는 내용입니다.

 

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

ListCollection lists = site.Lists;

IEnumerable<Microsoft.SharePoint.Client.List> listcollection =

context.LoadQuery(lists.Include(l => l.Title, l => l.Id));

context.ExecuteQuery();

listbox1.ItemsSource = listcollection;

listbox1.DisplayMemberPath = "Title";

 

 

결과는 다음과 같습니다.

작성한 코드는 주석처리하고 아래와 같은 코드를 입력합니다.

아래 코드는 사이트에 HJ 라는 공지사항을 생성하고 빠른 실행에 표시해주는 코드입니다. 이런 내용을 서버 개체 모델로 하는 것이 아니라 클라이언트 개체 모델로 해주고 있습니다.

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

ListCreationInformation listCI = new ListCreationInformation();

listCI.Title = "HJ";

listCI.TemplateType = (int)SP.ListTemplateType.Announcements;

listCI.QuickLaunchOption = SP.QuickLaunchOptions.On;

SP.List li = site.Lists.Add(listCI);

site.Update();

 

위에서 생성한 HJ라는 공지사항에 항목을 입력해보겠습니다. 작성된 코드를 주석처리하고

HJ를 찾아서 ListItem을 생성하는 코드를 아래와 같이 작성합니다. ListItemCreationInformation 이라는 클래스를 이용합니다.

 

ClientContext context = new ClientContext("http://sp.webtime.co.kr");

Web site = context.Web;

SP.List li = site.Lists.GetByTitle("HJ");

            ListItemCreationInformation listitemCI = new ListItemCreationInformation();

SP.ListItem item = li.AddItem(listitemCI);

item["Title"] = "hongju";

item["Body"] = "Consulting Services";

item.Update();

context.ExecuteQuery();

 

HJ 라는 공지 사항에 항목이 하나 추가되어 있는 것을 아래 그림과 같이 확인이 가능합니다.

위에서 Client Object Model에 대한 개요와 .NET Managed Client Object Model에 대한 내용을 알아보았습니다. 서버 개체 모델은 서버 박스 위에서 실행되는 웹 파트나 유틸리티를 통해 처리되지만 원격의 클라이언트에서 실행되도록 하려면 SharePoint 2010에서는 Client OM을 사용할 수 있습니다. 다음 블로그에서 Silverlight Client Object Model 을 알아보도록 하겠습니다.

 

- 위너를 고르는 방식!

위너라니, 무슨 위너이야기 일까요? 넵. 메서드 오버로딩에서 호출에 맞는 메서드를 고를때, 어떤 경우에 어떤 메서드가 더 적합한지 고르는, 즉 메서드 오버로딩 중에서 위너를 고르는 거에 대한 이야기 입니다. 아마도 이런 경우는 생각보다 자주일어날 것 같은데요. 과연 컴파일러는 어떤 방식으로 위너를 고를까요? 키로? 얼굴로? 능력으로? 한번 알아보시죠.


- 첫번째 경우

일단 두 메서드의 파라미터 개수가 같다고 할때는 매개변수가 어떤 타입의 파라미터로 형변환하는게 더 나은것인지를 기준으로 판단합니다.

class C {     public void Foo(object o) { Console.WriteLine("object"); }     public void Foo(int x) { Console.WriteLine("int"); }     static void Main(string[] args)     {         C c = new C();         c.Foo(10);     } }

그럼 위의 예제에서는 누가 위너가 될까요? 10은 정수니까, object로 형변환도 가능하고, int로도 형변환이 가능합니다. 하지만 정수는 object보다는 int로 형변환 되는게 더 적합한 형변환이죠. 그래서 여기서는 'Foo(int x)'가 위너가 됩니다. 'Foo(int x)' ㅊㅋㅊㅋ


- 두번째 경우

두번째 경우는 파라미터 배열이 끼어듭니다.

class C {     public void Foo(int x, int y) { Console.WriteLine("int twins"); }     public void Foo(params int[] x) { Console.WriteLine("params"); }     static void Main(string[] args)     {         C c = new C();         c.Foo(10, 20);     } }

첫번째 예제를 약간 변형시킨 건데요. 컴파일러는 파라미터 배열을 보자마자 이 파라미터 배열을 확장시켜서 메서드의 시그니처를 'Foo(int x_1, int x_2)'같이 만들고 이 시그니처를 가지고 오버로딩의 후보군에 끼워넣는다고 합니다. 그런데 컴파일러가 파라미터 배열을 확장만 시키는게 아니라, 파라미터 배열에서 확장되었음을 표시한다고 하네요. 그리고 파라미터에서 확장된 시그니처의 경우는 오버로드 판별에서 2등급으로 취급된다고 합니다. 즉 메서드 시그니처가 동일할 경우에 파라미터 배열은 2등급이기 때문에, 다른 일반적인 1등급 파라미터에 우선순위에서 밀리게 된다고 합니다. 위의 예제에서는 'Foo(int x, int y)'가 위너네요. ㅊㅋㅊㅋ


- 세번째 경우

이제 드디어 지금까지 열심히 이야기 해온 옵셔널 파라미터가 끼어들 차례입니다.

class C {     public void Foo(int x) { Console.WriteLine("int"); }     public void Foo(int x, int y = 0, int z = 10)     { Console.WriteLine("optionals"); }     static void Main(string[] args)     {         C c = new C();         c.Foo(10);     } }

위 예제는 쫌 난감합니다. 'c.Foo(10)'라는 호출만 보자면, 둘다 똑같이 해당되기 때문이죠. 첫번째 Foo는 시그니처가 완전히 일치하고, 두번째 Foo도 x를 제외한 값은 모두 기본값이 사용될 수 있으니까요. 이 경우에는 파라미터 배열과 같이 옵셔널 파라미터를 2등급으로 취급한다고 합니다. 즉 첫번째 Foo메서드가 옵셔널 파라미터가 하나도 없기 때문에 첫번째 Foo가 위너가 되는 것이죠. 그런데 만약에 첫번째 메서드에도 옵셔널 파라미터가 있다면 어떻게 될까요?

class C {     public void Foo(int x, int y = 0) { Console.WriteLine("optional1"); }     public void Foo(int x, int y = 0, int z = 10)     { Console.WriteLine("optional2"); }     static void Main(string[] args)     {         C c = new C();         c.Foo(10);     } }

위와 같이 작성된 경우 말이죠.

이런 에러를 보게됩니다. 즉, 둘간의 차이를 분별해낼 수 없기 때문에 모호한 호출이라는 것이죠.


- FAQ!

옵셔널 파라미터는 그동안 아주 꾸준히 C#에 추가해달라고 요청하던 기능입니다. 특히 오피스같은 COM과 연동하는 작업을 하는 프로그래머들이 많이 요청을 했었습니다. 왜 이런 기능을 예전에 안하고 지금하느냐? 하는 질문이 있을 법한데요. C#개발팀의 Sam Ng가 답변한 내용을 옮겨볼까 합니다.

1. 왜 이걸 좀 더 일찍하지 않았냐? - 왜 이걸 좀 더 일찍 하지 않았느냐 하면 말이죠. 우린 진짜 이 기능이 C#에 포함되지 않았으면 했습니다. 이걸 그동안 계속해서 미뤄온 건, 이건 우리가 원했던 패러다임이 아니었기 때문이었죠. 2. 그럼 왜 지금은 이걸 추가했느냐? - 이게 다 COM 때문이죠. 진짜 이건 사라지지를 않더라구요! 이걸 없앨려고 노력했지만, 사람들은 계속 이걸 사용하고 있고, 앞으로도 계속 사용하려고 하더군요. C#이랑 COM이랑 무슨 관계냐구요? 오피스. 오피스 PIAs때문이죠. 오피스 PIAs는 대부분 30개정도의 파라미터를 갖는 메서드로 이루어져 있죠. 그 파라미터의 대부분은 옵션이구요. 대부분의 경우에는 한개정도의 매개변수만 적어주고 나머지는 다 기본값을 사용하면 되는거죠. 이제 Named and Optional Parameters를 통해서 옵션인 파라미터는 안적고도 메서드를 호출할 수 있죠. 오피스 메서드를 호출할때도 모든 매개변수마다 Type.Missing같은거 안적어주고도 호출할 수 있는거죠. 그리고 매개변수에 해당하는 파라미터 이름을 적을 수 있기 때문에, 딱 필요한 거만 매개변수로 넘겨주고, 나머지는 생략할 수 있죠. 그리고 ref 없이 COM을 사용할 수 있도록한 기능과 조합해서 사용하면 COM 코드가 더 간결해지고 지루한 작업은 매우 줄어들겁니다. 컴파일러가 옵션인 ref 파라미터에 넘겨줄 임시값을 만들어서 매개변수를 넘겨주거든요. 제가 예전에 이야기 했듯이 C# 4.0의 큰 테마중의 하나가 다른 런타임(COM, 동적언어 등)과의 상호운용이에요. 그런 테마가 이런 기능을 반드시 갖추도록 했던거죠.

- 마치면서

아~ 이제 Named and Optional Parameters에 대해서 할말은 다 한것 같습니다. 자료를 읽으면서 저도 많이 배우고 재밌는 내용도 많이 읽었네요. 여러분은 어떠셨나요? 호호호호-_- 그럼 오늘은 여기까지 하고~ 다음에 또 다른 이야기 가지고 오겠습니다!


- 참고자료

1. http://blogs.msdn.com/samng/archive/2009/04/17/named-and-optional-arguments-ties-and-philosophies.aspx

Visual Studio 2010, 2008 버전에서는 .NET Framework 2.0, 3.5, 3.5 SP1 을 선택할 수 있는 Multi Targeting(멀티 타게팅) 기능을 제공합니다. 최신의 .NET Framework 버전을 선택하여 개발할 수 있으며, 하위 호환성 있는 개발을 위해 최신의 Visual Studio 에서 하위 .NET Framework 버전을 선택할 수 있습니다.

하지만 Visual Studio 2010, 2008 의 Multi Targeting 은 .NET Framework 1.x 를 지원하지 않습니다. 프레임워크 버전과 개발 도구간의 비호환성 문제 때문에 .NET Framework 1.x 버전은 Visual Studio 2003 으로만 개발이 가능합니다.

이번에 소개하는 방법을 통하여 Visual Studio 2010, 2008, 2005 도구를 이용하여 .NET Framework 1.x 를 개발할 수 있는 환경을 구성할 수 있습니다.

단, 기존의 Visual Studio 2003 은 MSBuild(Microsoft 통합 빌드 솔루션) 를 지원하지 않기 때문에, .NET Framework 4.0 SDK 에 포함된 MSBuild Targets 를 사용하였습니다.

(Visual Studio 2008, 2005 버전에서도 아래와 같은 방식으로 MSBuild Targets 을 수정하시면 .NET Framework 1.1 개발 및 빌드 환경을 구축할 수 있습니다)

   

Visual Studio 2003 으로 개발된 프로그램

아래와 같이 간단한 ConsoleApplication1 프로젝트를 만들었습니다.

이 응용 프로그램을 실행하면 다음과 같은 결과가 나옵니다.

Mscorlib.dll 의 버전이 1.0.5000.0 인 것을 확인할 수 있습니다.

   

Visual Studio 2010 으로 프로젝트 컨버팅 하기

만들어진 Visual Studio 2003 프로젝트를 Visual Studio 2010 버전으로 컨버전합니다.

컨버전이 완료되었으면 프로젝트 파일(.csproj) 을 열어 아래와 같이 수정합니다.

먼저 기존의 .NET Framework 어셈블리를 .NET Framework 1.1 의 어셈블리로 강제로 변경해 줍니다. Visual Studio IDE 에서 .NET Framework 1.1 을 추가하면 2.0 이상의 어셈블리가 추가되므로 반드시 .csproj 파일에서 변경해 주어야 합니다.

그리고 Import 노드에 Microsoft.Csharp.v1.1.targets 의 라인을 추가해 줍니다.

   

Microsoft.CSharp.v1.1.targets 파일 만들기

$(MSBuildToolsPath) 의 폴더인 C:\Windows\Microsoft.NET\Framework\v4.0.30128 경로에서 Microsoft.CSharp.targets 파일의 복사본 이름을 Microsoft.CSharp.v1.1.targets 파일로 만들어 줍니다.

위의 방법으로 Microsoft.Common.target 파일을 Microsoft.Common.v1.1.targets 파일 이름으로 복사본을 만듭니다.

 

Microsoft.CSharp.v1.1.targets 파일 수정하기

아래의 노드를 찾아서 <NoWarn> 노드의 1701; 1702 값을 제거합니다. 이 값은 .NET Framework 1.1 의 경고 값으로 사용할 수 없는 값입니다.

그리고 아래의 CSC 노드를 찾아서 ErrorReport 속성을 제거합니다. .NET Framework 1.1 SDK 의 CSC.exe 는 ErrorReport 기능이 존재하지 않기 때문입니다.

추가로 CSC 노드의 ToolPath 의 경로를 아래와 같이 수정합니다. 이 경로에 포함되는 csc.exe 를 사용하여 .NET Framework 1.1 로 빌드하는 중요한 구문입니다.

아래의 Import 노드를 찾아서 복사본으로 만들었던 Microsoft.Common.v1.1.targets 파일명으로 변경합니다.

   

Microsoft.Common.v1.1.targets 파일 수정하기

아래의 노드를 찾아 붉은 영역의 노드를 추가합니다. 만약 TargetFrameworkVersion 노드를 .csproj 파일에 명시적으로 수정하게 되면, Visual Studio 2010 은 v2.0 이상 버전으로 변경을 해야 프로젝트 파일을 로드할 수 있기 때문에 Microsoft.Common.v1.1.targets 파일에서 변경해야 합니다.

아래의 ReportingServiceTargets 노드를 찾아 주석으로 처리하거나 삭제합니다.

아래의 _DebugSymbolsIntermediatePath 노드의 ItemGroup 을 주석으로 처리합니다. $(IntermediateOutputPath) 이미 기존의 Microsoft.CSharp.targets 에서 값이 선언되었으므로 같은 값이 추가되거나 할 경우 Collection Type 으로 간주하기 때문에 이 구문은 필요가 없습니다.

마찬가지로 아래의 구문도 $(IntermediateOutputPath) 는 Collection Type 으로 처리가 되는 것을 방지하기 위해 아래의 구문도 주석으로 처리하거나 제거합니다.

아래의 구문도 위와 같은 이유로 제거하거나 주석으로 처리합니다.

아래의 Code Analysis 기능은 Visual Studio 2003 에서 통합되어 제공되지 않기 때문에 제거하거나 삭제합니다.

   

Visual Studio 2010 에서 .NET Framework 1.1 빌드 하기

모든 구성이 완료 되었으면, Visual Studio 2010 에서 ConsoleApplication 을 실행해 봅니다. 빌드가 .NET Framework 1.1 로 빌드된 것을 확인할 수 있습니다.

   

 

SourceSafe 보다 더 좋은 VS TFS 2010  3부작~ 1편

 

울 팀장 : "XX 씨~"

나 : "네~(룰루 랄라~)"

울 팀장 : "현재 쓰고 있는 VS 2008 하고 VS 2005는 SourceSafe 에 있는거 사용하고, 신규부터 VS TFS 2010 사용하죠."

나 : "네? 그거 전부 VS TFS에 올리는 거 아닌가용????"

울 팀장: "잉? 뭐야 VS 2008에 있는거? VS TFS 2010으로 연결해서 사용할 수 있어? 그리고 TFS 2010 에서 소스 관리하는거 새로 배워야 하는거 아냐?"

나 : "네??? 왜 새로 배워요? 걍 SourceSafe 사용했던 것 처럼 체크 인/ 아웃 하면 돼요~"

울 팀장: "새로 안배워도 돼? 정말? 그리고 VS 2008 에 있는거 SourceSafe 말고 VS TFS 2010 써도 돼?"

나 : "네~~~ 훠~~ 얼씬 안정빵으로 소스 관리할 수있어요~ 이번에도 저만 믿으세요~ ㅋㅋㅋㅋ(이번엔 울 팀장에게 저녁 사달라 할까? 울 마눌님 친정갔는데 ㅋㅋㅋ)"

울 팀장 : "오 그래? 해봐"(킁 이번에도 밥 내기 해봐? 그런데 저 웃음은 뭐지??? 킁 불안해 확실할 때 해야겠당...)

 

넵 이제 드뎌 사용편입니다. 3부작으로 천천히 하죠 ㅎㅎㅎ

1편 : VSS 에서 VS TFS 2010으로 업그레이드 준비 작업하기
 

사용편에서는 Visual SourceSafe 2005를 사용하는 사용자 분들을 위해 앞에서 설치, 구성을 한 상태에서 진행하셔야 합니다. VS TFS 2010 을 우선 기존의 사용하는 방법 그대로 사용하면서 추가 기능을 알아보는게 더 좋을 것 같습니다.

 

즉~ Visual SourceSafe 2005(VSS 2005) 업그레이드 대 작전(?) 입니다.

 

VSS 2005 이라고 불리는 녀석이 울 회사 프로젝트의 모든 소스를 관리하는 녀석으로 한 20개 정도가 있다고 가정합니다.~ (가정 넵 요 VS 2005 하고 2008 같이 사용하는 회사도 있습니다. ^^)

 

울 회사는(전 백수입니다 ㅠ.ㅠ) VS 2005 부터 VS 2008 까지 프로젝트로 진행하고 있으며 개발자들은 모두 두개의 VS 를 설치하고 있다고 가정합니다. 이런 상황에서 VS TFS 2010을 사용할 수 있으냐? 넵 사용 가능합니다. 처음 부터 VS 2010을 사용하면 좋지만… 여러가지 이유로 당분간 VS 2005, 2008 을 사용해야 하는 어쩔수 없는 상황도 있을 수 있습니다.

 

울 VS TFS 2010을 만들어낸 Microsoft 에서는 이런 상황에 대한 지원은 기본이라 할 수있습니다.( VS 2003 은 번외편으로 하죠 ㅎㅎ 아직 완전하지는 않은듯 합니다 ^^ 제가 테스트 하구요^^)

 

이제 본론으로 넘어와서 이 TFS 2010 이란 녀석을 활용해야 하는데.. 솔직히 기존 프로젝트를 VS 2010으로 업그레이드 하는 것이 젤루 좋지만…. 앞에서 설명한 여러가지 이유중에 회사마다 돈을 내고 사용하는 VS의 추가 콤포넌트들이 있을 경우에는 바로 업그레이드 하기에는 조금 위험하기 때문에.. 그냥 VS의 기존 버전을 사용하는 경우도 있습니다. 그렇다면, 정말 연결을 하려면 어떻게 해야 하는가??

기존 버전에서 VS TFS 2010으로 연결하기 위해서는 다음 과 같은 파일들을 다운로드 받아서 설치만 하면 됩니다.

 

VS 2005 SP1 용 호환성 업데이트

VS 2008 SP1 용 호환성 업데이트

 

오~ 이 2개만 있으면.. 바로 사용할 수 있다는 것입니다.(한글판 다운로드입니다.^^)

 

그런데~~ 여기서 잠깐 주의 하실 것이 있습니다.

 

VS 2005에서는 최소한 Visual Studio Team System 제품군이여야 한다는 전제조건이 있습니다. VS 2008은 Professional 에서 Team Explorer 2008을 설치해서 접속해도 되지만… VS 2005는 약간 부끄러움을 타는건지(?) Team System 계열만 가능합니다.

 

또 하나. 바로 Service Pack관련 부분으로 어느 회사에서는 Service Pack1을 설치하지 않는 경우도 있습니다. 이 Service Pack1은 닷넷은 아닙니다. 개발자분들이 오해하시는 것중에 하나가 .NET 서비스팩 업그레이드 했으니 VS도 업그레이드 된거 아냐? 하시는데.. 넵 아닙니다.

그래서 절대 주의 하셔야 합니다.

 

Visual SourceSafe 2005 에서 Visual Studio Team Foundation Server 2010 으로 가기 위한 작업

 

Visual Studio 2005 인 경우

 - Visual Studio Team System 제품군인지 확인

 - Visual Studio Team Explorer 2005 설치

 - Visual Studio 2005 Service Pack 1 설치

 

Visual Studio2008 인 경우

 - Visual Studio Team Explorer 2008 설치

 - Visual Studio 2008 Service Pack 1 설치

 

이런 순서로 진행하셔야 합니다.

 

Service Pack 1 설치 후에 Team Explorer을 설치하시면.. 다시 Service Pack 1 을 설치하셔야 합니다.

그런 이제 VS TFS 2010을 접속할 수 있는 환경으로 전환이 된 것 입니다.

 

그런데… 울 회사 개발팀들.. 한 마디 씩 합니다. 왜 TFS 2010으로 가야 하는데????

윽~ 걍 소주 한잔 하시죠?? 하고 이야기 하면.. 소주값 만이 들어갑니다.(한달 월급이 얼마인데 ㅠ.ㅠ 잘못 카드값이 나오면 마눌님에게 둑는데 ㅠㅠ)

 

그래서 다음과 같이 정리 했습니다.

 

 

ㅎㅎㅎ 넵.. 이런 이유로 사용하면 좋다는 것인데요.. 일단 VSS 2005 아니 VSS 오랫 동안 사용해보신 분들이라면.. 다들 VSS 때문에 약속이나 소스 원복으로 인한 철야 작업들이 기억나실 겁니다.

 

VS TFS는 SQL Server를 사용하기 때문에 DB 백업/복구만 잘되어 있다면 언제든지 복구가 가능하다는 것이죠. SQL 이긴 하지만, Database의 장점과 Windows의 계정의 활용등등.. 여러 가지 장점이 있다는 것입니다. 앞에서 정리한 것으로 개발팀원들과 이야기가 끝났다면… 이제 사용해야 겠죠?

 

넵.. 바로 Service Pack 1 설치 다음이 사용자 계정과 소스를 TFS 2010으로 이전 작업입니다.

사용자 계정과 소스 이전 작업은 다음에~~ Soon 입니다~