public void lock() { while (!owner.compareAndSet(false, true)) LockSupport.parkNanos(1); }강의에서 직접 구현하신 스핀락에서 LockSupport.parkNanos()를 사용하셨을 때, 컨텍스트 스위칭이 발생하지 않는다고 설명해주셨는데요.실제로 예제 코드에서 Thread.getState()로 스레드 상태를 확인해보니, parkNanos() 호출 시 스레드가 TIMED_WAITING 상태로 전환되었다가 지정한 시간이 지나면 RUNNABLE 상태로 바뀌는 것을 확인했습니다.그렇다면 지정한 시간이 지난 후 RUNNABLE 상태가 되었을 때, 해당 스레드에 대해 컨텍스트 스위칭이 발생하는 것이 아닌지 궁금합니다.또한 강의에서는 parkNanos()가 실제로 블로킹되는 것이 아니라 내부적으로 스피닝한다고 설명해주셨는데, 만약 그렇다면 스레드 상태가 RUNNABLE이어야 하지 않을까 하는 의문도 들었습니다.이 부분이 조금 혼란스러워 이렇게 질문드리게 되었습니다.  

안녕하세요:)강의를 듣고 궁금한 점이 있어 질문드립니다. 44강과 45강에서 List에 대해 설명해 주시면서 일반적인 상황에서는 ArrayList나 LinkedList를, 동시성 문제가 고려되어야 하는 상황에서는 Vector를 사용하라고 말씀해 주셨습니다. 그런데 Vector는 JDK 1.x 시절에 도입된 레거시 클래스로 모든 public 메서드에 synchronized 키워드가 적용되어 있어 성능 저하와 불필요한 락 경쟁, 캐시 무효화 등의 문제가 발생할 수 있는 것으로 알고 있습니다. 그래서 현재는 java.util.concurrent 패키지에서 제공하는 동시성 컬렉션이나, Collections.synchronizedList, CopyOnWriteArrayList와 같은 대안들을 상황에 맞게 사용하는 것이 더 적절하다고 알고 있습니다. 이러한 이유로 단순히 동시성 문제를 고려해야 하는 상황에서 Vector를 권장한다라는 접근은 현재 시점에서 어울리지 않는다고 생각됩니다. 그럼에도 강의에서 Vector를 언급하신 특별한 의도나 배경이 있으셨는지 궁금하여 질문드립니다 :)

제가 cs가 조금 약해서 그런데...커널객체랑 jvm내 객체랑..크게 보면 같은 의미라고 할수있나요? 자바에서 객체는 JVM이 관리하는 메모리 내 인스턴스--> 인데... 커널 객체도... 만약에 C로 짜여진 운영체제라면..네이티브 메모리에 올라가있는 데이터구조 인스턴스..?라고 해야하나 그런걸 의미하는걸까요?

선생님께서 말씀하시는 TLS는 프로세스의 한정적인 VMS위에서 나뉘어서 사용되는건가요?? Heap area에 비해 다른 영역은 작은걸로 아는데 TLS가 나뉘어서 사용되면 영역이 작아지지 않을까라고 생각되서 질문드립니다!!

lock flag로 스레드가 인스턴스에 접근한다고 하셨습니다. 그런데 멀티스레드에서는 동시에 인스턴스에 접근하여 각각 코어에서 연산을 하기 때문에 동기화 문제가 발생합니다. 그럼 항상 lock flag을 획득하고 접근하는게 아닌가요? 그리고 스레드가 함수 단위라 하셨는데, write 과정을 cpu 스케줄링 관점에서 생각하면Time slice 내에서 load, read 하고 기다린 뒤 다시 자신의 차례가 왔을 때 memory에 write한다고 이해했는데 맞나요? 또한 synchronized를 이용하면 원자성이 보장된다고 하셨습니다. 그렇다면 복잡한 로직과 관계 없이 synchronized를 붙이면 스케줄링 없이 한방에 실행되는 건가요?  마지막으로.. 서버를 겉햝기식으로 공부하다가 회의감이 들어 널널한 개발자님 강의를 들으며 jvm, 자바부터 다시 공부하고 있습니다. 하지만 공부를 하면서 불안하고 회의감이 듭니다. 왜 이런 감정이 드나 생각해보았더니 jvm, 멀티스레드를 프로젝트에 어떻게 녹여서 포트폴리오화 해야 할지 모르는 막막함 때문이었습니다. 제 생각에 조언, 지적을 해주실 수 있나요? 

안녕하세요!동시에 TryPop() 을 할 경우, oldHead를 참조하는 스레드가 있을 수 있고 이 때 무작정 해제해버리면 use after delete 오류가 발생할 수 있다고 하셨습니다.TryDelete() 함수를 구현하실 때, 1 == popCount 안에서 delete old_head 를 할 때는 이미 분리했으니까 괜찮다고 하셨는데요. 첫 문단에서 언급한 부분과 반대되는 말을 하신 것 같다는 느낌을 받았습니다.제가 생각했을 때는, 저희 수업 때 사용하신 예제 코드에서는, cas 연산을 통해 oldHead 를 분리했기 때문에 use after delete 오류가 안 날 것 같단 생각이 들더라고요.궁금해서 테스트를 해봤습니다.TryDelete() 함수를 호출하지 않고 바로 delete old_head; 를 호출하는 코드를 넣었고요, 지금 이 질문을 올리고 있는 와중에 push() 는 sleep_for(1ms)를 주고 pop()을 하는 스레드는 5개를 돌려서, 진단 도구에서 확인되는 프로세스 메모리가 1mb이 유지되게 설정해서 30분 넘게 돌려보고 있습니다. 오류가 안 나고 있는 광경을 목격 중입니다. 그냥 운이 좋은 걸까요?오류가 발생하지 않는 이유는 다음과 같다 생각합니다.atomic 변수인 head에서 cas 연산을 하기 때문에 간발의 차이로 먼저 다음 코드를 통과한 스레드가 획득한 oldHead는 다른 스레드가 이후에 될 oldHead와 같지 않다. while 조건에서 true를 반환하는 순간 head는 head의 next를 가리키고 있게 되기 때문이다. compare_exchange_weak() 함수가 true를 반환하면 head는 원자적으로 head->next를 가리키는 상태가 된다.while (old && false == _head.compare_exchange_weak(old, old->next)) return false; 고견 부탁드립니다.멋진 강의 감사합니다.

강의 하실때 lock방식과 lock-free방식에 성능 차이가 없다는 것처럼 이야기 하셔서, 왜 성능 차이가 없을까 라는 것을 생각 해 보면, 주로 성능 차이가 어디에서 오냐를 먼저 고민해 봐야 할 것입니다. 저의 생각으로는, 정상적인 상황에서 Context switching으로 인해 커널 - 유저 모드 전환에서 큰 비용이 발생한다고 생각이 됩니다. 전통적인 Event 방식이 대표적인 예라고 생각합니다. 작업하신 lock-free 방식을 볼때마다 spinlock이 계속 떠올랐습니다.  결국 User mode에서 polling하고 있는 것이 겠지요. 어디서 주워 듣기로는 요즘 lock들도 커널 모드로 바로 들어가 일정시간 잠들지 않고, user mode에서 3000번, 5000번  정도 while을 돌면서 소유권을 얻을 수 있는지 확인한다고 합니다. 그 횟수동안 얻지 못하면 sleep 되는 식으로 알고 있습니다. 결국 빠르게 소유권이 전환되는 상황이라면 user mode에서만 작업이 발생하기 때문에 큰 overhead가 없다고 볼 수 있을 것 같습니다. 이러한 이유로 두 방식의 성능 차이가 거의 없다고 보는데 다른 분들의 의견이 궁금합니다.

예제 코드를 보면 TryPop을 아래와 같이 구현하고 있습니다. bool TryPop(T& outData) {     Node* oldHead = _head.load();          Node* expected = oldHead;     Node* desired = oldHead->Next;     while (oldHead && false == _head.compare_exchange_weak(expected, desired))     {         // Null     }     if (_head.load() == nullptr)     {         return false;     }     // 이하 생략 } 혹시 위의 코드에서 아래처럼 미리 Null check를 해도 무관할까요? bool TryPop(T& outData) {     if (_head.load() == nullptr)     {         return false;     }     Node* oldHead = _head.load();          Node* expected = oldHead;     Node* desired = oldHead->Next;     while (false == _head.compare_exchange_weak(expected, desired))     {         // Null     }     // 이하 생략 } 실제로 돌렸을 때는 문제가 없었는데, 혹시 제가 간과한 부분이 있나 하여 여쭤봅니다.