ConcurrentDictionary in Unity

.Net 쪽에서는 Concurrent Collection이라고해서

lock-free Collection을 제공한다. 작업하다보면, 한쪽 스레드에서는

컬렉션에 입력만 하고, 한쪽 스레드에서는 해당 컬렉션을 읽기만 할때가 있는데

lock을 걸거나 readwritelock (slim)을 쓰기에는 뭔가 아까운 느낌인데

Concurrent 시리즈가 lock 없이 접근 가능하다는 구현방법이 마음에 들어서

서버쪽에서 자주 애용했는데

유니티는 .net 3.5라서 해당 collection이 제공이 안되어서 아쉬워하다가

검색해보니 다음 두가지 방법으로 사용 가능한 것으로 보인다.

(사실 모든 폰에서 테스트를 해봐야 정확할 것 같다.)

 

  1. https://www.nuget.org/packages/TaskParallelLibrary/
  2. https://github.com/SaladLab/NetLegacySupport

 

1번은 꽤 오래된(2012.04.14.) TPL이고,

2번은 공개된 .net 코드가 3.5환경에서 컴파일이 되도록 수정된 버전이다. 대규모 사용 등으로 안정성은 아직 검증이 많이 된것은 아니지 않나 싶다. Saladbowl이라는 게임 벤쳐회사에 재직중인 TD님이 올려주신 코드. Concurrent 시리즈 중에 Dictionary만 있다.

가볍고 최신 코드기반으로 적용된 2번을 사용하려고 하다가 한번 더 검색을 해봤는데

http://blogs.msdn.com/b/pfxteam/archive/2011/11/08/10235147.aspx

위와같은 공개된 테스트가 있어서

.Net 3.5 에서 컴파일한 1번과 2번 ConcurrentDictionary와

.Net 4.5.2에서 컴파일한 ConcurrentDictionary의 테스트를 위 테스트 코드로 해보았다.

example1은 인풋을 0으로 했고 결과는 다음과 같다.

result

.Net 4.5쪽이 당연히 가장 빨랐고

example1과 example2는 TPL이, example3은 netlegacysupport쪽이 빨랐다.

즉, 한쪽 키에 몰릴경우에는 tpl이 빠른데, 평균적으로 분산될 경우 게다가, 멀티스레딩환경

이라면 유니티에서 사용하기에는 netlegacysupport쪽이 낫다는 결론이 나왔다.

 

추가. Net 3.5에서 Parallel.Invoke는 TPL에 있는 버전을 사용하여

4.5에서의 성능과 3.5에서의 성능을 실질적으로 비교하긴 힘듬

ConcurrentDictionary in Unity

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s