Game server 만들기 4일차

echo 서버는 어제 완성함. 머 학부때 한거 보다 나아진건 Exception, name space 사용이 좀 나아졌다는거?

12:27 - 오늘 하루 하지마루요

머하지;

요즘 급한건

1. 포트폴리오 없따 - 플래피 버드를 낼 수 있는 것도 아니고

2. 설계 능력 부족 - 여러 사람이 건들여도 될 만큼 구조를 잡을 능력이 부족하다.

    Dropbox닮은 mac버전 설계, Office MFC 버전 설계 모두 버겁게 느껴졌음.

    결국엔 내가 안하게 되었지만. 디자인 패턴 책을 봐도 답은 아니 나오고 흠

그래도 서버를 짤 것인가?

1. C++ Concurrency in Action - 2년이 지나도 아직 못봄

2. SICP - 봐야지?

http://clojure.egloos.com/viewer/3645778

intel - 크롬, 웹킷 committer vs NC 출신 게임 공학과 부교수

흠 게임 서버 쪽에 lock free 효용성에 대해 싸우던데

한쪽은 경력이 ㅎㄷㄷ 고 한쪽은 해당 업계 경력자고

누가 옮은 건가. 그리고 왜 난 저기에 대해 아무것도 몰라서 끼지도 못하지?

해야할 건 많다. 계획 잡고 차근 차근 해나가자.

흠 우선 volatile은 intel이 맞다. 이건 3번째 보는데 난 맨날 까먹노

http://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming

http://minjang.egloos.com/2274079

stack overflow쪽 내용이 좋음.

The problem with volatile in a multithreaded context is that it doesn't provide all the guarantees we need. It does have a few properties we need, but not all of them, so we can't rely on volatile alone.

However, the primitives we'd have to use for the remaining properties also provide the ones that volatile do, so it is effectively unnecessary.

For thread-safe accesses to shared data, we need a guarantee that

• the read/write actually happens (that the compiler won't just store the value in a register instead and defer updating main memory until much later)
• that no reordering takes place. Assume that we use a volatile variable as a flag to indicate whether or not some data is ready to be read. In our code, we simply set the flag after preparing the data, so all looks fine. But what if the instructions are reordered so the flag is set first?

volatile does guarantee the first point. It also guarantees that no reordering occurs between different volatile reads/writes. All volatile memory accesses will occur in the order in which they're specified. That is all we need for what volatile is intended for: manipulating I/O registers or memory-mapped hardware, but it doesn't help us in multithreaded code where the volatile object is often only used to synchronize access to non-volatile data. Those accesses can still be reordered relative to the volatile ones.

The solution to preventing reordering is to use a memory barrier, which indicates both to the compiler and the CPU that no memory access may be reordered across this point. Placing such barriers around our volatile variable access ensures that even non-volatile accesses won't be reordered across the volatile one, allowing us to write thread-safe code.

However, memory barriers also ensure that all pending reads/writes are executed when the barrier is reached, so it effectively gives us everything we need by itself, making volatile unnecessary. We can just remove the volatile qualifier entirely.

3	An MSDN example does this, and claims that instructions can't be reordered past a volatile access:msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx –  OJW Sep 16 '11 at 15:06
13	@OJW: But Microsoft's compiler redefines volatile to be a full memory barrier (preventing reordering). That's not part of the standard, so you can't rely on this behavior in portable code. –  jalf Oct 4 '11 at 7:00

15:23 - 놀랍게도 이거 읽는데 3시간 걸림 ㅎㅎ 머했지 이거 저거 찾고 c++11 thread한번 뛰어본게 다인데

19:06 - 샌드위치 사먹고 집에옴. 머했는지 말하기 그렇네

인터넷에서 잡지식 배우는 것도 좋지만 교과서나 책 위주로 때는게 정리가 잘되는 듯.

22:47 - 안그래도 공부 안되서 애니보고 놀다가 (재미가 없어...) 본가에서 올라온다는 소리에 

집 치움.