인프런 커뮤니티 질문&답변
작성한 질문수
name을 왜 자신의 클래스 이름으로 하나요?
작성
·
396
0
lockId는 모든 lock마다 1개씩 있어야 하는 것 아닌가요?
그런데 제 생각으로는 name을 자신의 클래스 이름으로 하면 같은 클래스 이름을 가진 다수의 lock이 생기는데, 모든 lock마다 lockId가 1개씩 생길 수 없습니다.
예를 들어 A라는 클래스의 객체가
- WriteLock을 걸고,
- WriteLock을 풀지 않은채로 ReadLock을 걸었습니다.
그러면 1번에서 건 WriteLock은 PushLock 함수 내에서 A라는 name으로 새로운 Id인 0번 Id를 받게 될 것입니다.
그 후 2번에서 건 ReadLock은 PushLock 함수 내에서 A라는 name을 찾은 결과 이미 0번 Id를 가지고 있었기 때문에 또 다시 0번 Id를 받게됩니다.
그러면 WriteLock과 ReadLock은 서로 다른 lock인데도 똑같이 0번 Id를 가지게 됩니다.
위의 생각에서 잘못된 부분이 무엇인가요? 혹은 제가 놓치고 있는 부분이 무엇인가요?
답변 3
0
0
A->B와 B->A 순서로 락을 잡을 수 있는 상황이 있다면 그 자체로 문제인 것은 이해했습니다. 데드락이 발생하니까요. 그리고 A와 B는 다른 lockId를 부여받아 DeadLockProfiler에 검출되겠죠?
그런데
A 클래스로 각기 다르게 동적할당한 a1, a2, a3 인스턴스로 구분하는 것은 큰 의미가 없다는 것이 왜 그런지 이해가 잘 안됩니다..ㅠ
예를 들어
a1 -> a2로 lock을 거는 thread1과
a2 -> a1로 lock을 거는 thread2가 있을 때에도 위와 마찬가지로 데드락이 걸리는 상황이 아닌가요?
그런데 같은 A클래스의 인스턴스인 a1과 a2는 같은 lockId를 받아 재귀 락으로 인식되고 DeadLockProfiler에 검출되지 않을 것이라고 생각됩니다... 아닌가요?
0
각기 다른 lock에 id를 다르게 부여하면
확률적으로 일어나는 상황을 잡을 수 없습니다.
class A, class B가 있는 상황에서
A->B와 B->A 순서로 락을 잡을 수 있는 상황이 있다면 그 자체로 문제입니다.
즉 A 클래스로 각기 다르게 동적할당한 a1, a2, a3 인스턴스로 구분하는 것은 큰 의미가 없습니다.
중첩 Lock을 허용하는 경우 연속해서 Write-Write-Read를 동일 락에 대해 하는 것은 별다른 문제가 없습니다.
네 말씀하신 부분대로 재현을 한다면 그게 맞지만,
동일한 클래스의 다른 인스턴스끼리 저렇게
락을 거는 코드는 정말 희박합니다.
User 라는 클래스를 기준으로 user1, user2, user3가 있다고 했을 때
특정 정보를 갖고 오는 user1->GetStatInfo();와 같은
특정 함수가 락으로 묶여 있을 수는 있겠지만,
그 특정 함수에서 또 다른 user2의 뭔가를 빼내는 코드가 만들어지는 것은 상상하기조차 힘듭니다.
일반적으로 데드락은 SessionManager, UserManager와 같이
서로 다른 클래스 사이에서 일어나는 경우가 99%라고 볼 수 있겠습니다.