맨위로가기

락 (컴퓨터 과학)

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

락(Lock)은 컴퓨터 과학에서 공유 자원에 대한 동시 접근을 제어하기 위한 동기화 메커니즘이다. 락은 여러 스레드 또는 프로세스가 동시에 동일한 데이터에 접근하여 발생할 수 있는 데이터 손상이나 일관성 문제를 방지하는 데 사용된다. 락은 권고 락과 강제 락으로 나뉘며, 세마포어, 스핀락 등 다양한 유형이 존재한다. 락은 하드웨어 지원을 받아 원자적 연산으로 구현되며, 프로그래밍 언어는 상호 배제 API를 제공하여 락을 지원한다. 락의 부주의한 사용은 교착 상태나 라이브락을 발생시킬 수 있으며, 락의 세분성은 락 오버헤드와 동시성 간의 트레이드오프를 결정한다. 락 기반 프로그래밍은 경합, 오버헤드, 디버깅의 어려움 등의 문제점을 가지며, 이를 해결하기 위해 락-프리 프로그래밍, 소프트웨어 트랜잭션 메모리 등의 대안이 제시된다. 데이터베이스에서는 비관적 락과 낙관적 락을 사용하여 트랜잭션의 동시성을 관리한다.

더 읽어볼만한 페이지

  • 동시성 제어 - 세마포어
    세마포어는 데이크스트라가 고안한 정수 변수로, P/V 연산을 통해 자원 접근을 제어하고 동기화 문제를 해결하며, 계수 세마포어와 이진 세마포어로 나뉘어 멀티스레드 환경에서 자원 관리 및 스레드 동기화에 기여한다.
  • 동시성 제어 - 모니터 (동기화)
    모니터는 공유 자원 접근을 제어하여 프로세스 간 동기화를 구현하는 프로그래밍 구조로, 뮤텍스 락, 조건 변수 등으로 구성되어 경쟁 상태를 방지하며 여러 프로그래밍 언어에서 지원된다.
  • 소프트웨어 디자인 패턴 - 모델-뷰-컨트롤러
    모델-뷰-컨트롤러(MVC)는 소프트웨어 디자인 패턴으로, 응용 프로그램을 모델, 뷰, 컨트롤러 세 가지 요소로 분리하여 개발하며, 사용자 인터페이스 개발에서 데이터, 표현 방식, 사용자 입력 처리를 분리해 유지보수성과 확장성을 높이는 데 기여한다.
  • 소프트웨어 디자인 패턴 - 스케줄링 (컴퓨팅)
    스케줄링은 운영 체제가 시스템의 목적과 환경에 맞춰 작업을 관리하는 기법으로, 장기, 중기, 단기 스케줄러를 통해 프로세스를 선택하며, CPU 사용률, 처리량 등을 기준으로 평가하고, FCFS, SJF, RR 등의 알고리즘을 사용한다.
락 (컴퓨터 과학)
동기화 메커니즘
목적공유 리소스에 대한 접근 제한을 강제하는 동기화 메커니즘
종류뮤텍스 (상호 배제)
세마포어
스핀락
읽기-쓰기 락
재진입 락
사용 예시다중 스레드 환경에서 공유 데이터 보호
데이터베이스 트랜잭션에서 동시성 제어
운영체제 커널에서 자원 관리
작동 방식락 획득: 공유 리소스에 접근하기 전에 락을 획득해야 함.
락 해제: 공유 리소스 사용 후 락을 해제하여 다른 스레드가 접근할 수 있도록 함.
장점데이터 무결성 유지
경쟁 조건 방지
예측 가능한 프로그램 동작 보장
단점데드락 발생 가능성
성능 저하 (락 획득/해제 오버헤드)
우선순위 역전 문제
주의사항락 사용 범위를 최소화하여 성능 저하를 줄임.
데드락 방지 전략을 고려함. (락 획득 순서, 타임아웃 등)
적절한 락 종류를 선택함. (뮤텍스, 세마포어, 스핀락 등)
관련 용어임계 구역
상호 배제
세마포어
데드락
경쟁 조건
구현운영체제 커널
프로그래밍 언어 (예: 파이썬의 `Lock` 객체)

2. 유형

락은 크게 어드바이저리 락(Advisory Lock)과 맨더터리 락(Mandatory Lock)으로 나뉜다. 어드바이저리 락은 각 스레드가 데이터에 접근하기 전에 락을 획득하여 협력하는 방식이다. 반면, 맨더터리 락은 잠긴 자원에 대한 비인가 접근 시 예외를 발생시켜 강제성을 부여한다.[1]

가장 기본적인 락은 이진 세마포어로, 배타적 접근을 제공한다. 즉, 한 번에 하나의 스레드만 데이터에 접근할 수 있다. 이 외에도 데이터를 읽기 위한 공유 접근을 허용하는 락도 존재한다. 널리 구현되는 접근 모드로는 배타적(exclusive), 배제 의도(intend-to-exclude), 업그레이드 의도(intend-to-upgrade) 등이 있다.[1]

락 전략에 따라, 락은 락을 요청하는 스레드 (컴퓨터 과학)의 실행을 차단 (컴퓨팅) 할 수 있다.

2. 1. 동작 방식

락은 일반적으로 효율적인 구현을 위해 하드웨어 지원이 필요한데, 이는 보통 "테스트 앤드 세트", "페치 앤드 애드" 또는 "비교 후 교환"과 같은 하나 이상의 원자적 연산 명령 형태로 제공된다.[1] 이러한 명령을 통해 단일 프로세스는 락이 비어 있는지 확인하고, 비어 있으면 단일 원자적 연산으로 락을 획득할 수 있다.

단일 프로세서 환경에서는 특수 명령이나 명령 접두어를 사용하여 인터럽트를 일시적으로 비활성화하는 방식으로 중단 불가능한 시퀀스를 구현할 수 있지만, 멀티 프로세서 공유 메모리 환경에서는 이 방법이 효과가 없다.[1] 멀티 프로세서 환경에서 락을 제대로 지원하려면 복잡한 하드웨어나 소프트웨어 지원과 함께 상당한 동기화 (컴퓨터 과학) 문제가 발생할 수 있다.

원자적 연산이 필요한 이유는 여러 작업이 동시에 동일한 로직을 실행하는 동시성 때문이다. 예를 들어 다음과 같은 C (프로그래밍 언어) 코드를 보자.

```c

if (lock == 0) {

// lock free, set it

lock = myPID;

}

```

위의 코드는 여러 작업이 동시에 락을 검사할 수 있기 때문에 작업이 락을 소유하고 있는지 보장하지 못한다.[1] 두 작업 모두 락이 비어 있음을 확인하고 락을 설정하려고 시도할 수 있지만, 다른 작업도 락을 설정하려고 한다는 사실을 인지하지 못한다. 원자적 락 연산을 사용할 수 없는 경우 데커의 알고리즘 또는 피터슨의 알고리즘을 대안으로 사용할 수 있다.

스핀락은 스레드가 락을 사용할 수 있게 될 때까지 단순히 대기("스핀")하는 방식이다.[1] 이는 스레드가 짧은 시간 동안 차단될 때 효율적인데, 운영 체제 프로세스 재스케줄링으로 인한 오버헤드를 피할 수 있기 때문이다. 그러나 락이 오랫동안 유지되거나 락을 소유한 스레드의 진행이 락을 기다리는 스레드의 선점에 의존하는 경우에는 비효율적이다.

3. 언어 지원

다양한 프로그래밍 언어에서 동기화를 지원한다.


  • C#는 `lock` 키워드를 제공하여 스레드가 리소스에 독점적으로 접근할 수 있도록 한다.
  • 자바는 `synchronized` 키워드를 통해 코드 블록, 메서드, 객체를 잠글 수 있으며,[11] 동시성 안전 데이터 구조를 가진 라이브러리를 제공한다.
  • 오브젝티브-C는 `@synchronized` 키워드로 코드 블록에 잠금을 적용하고,[12] NSLock,[13] NSRecursiveLock,[14] NSConditionLock[15] 클래스와 NSLocking 프로토콜[16]을 제공한다.
  • VB.NET은 C#의 `lock`과 유사한 `SyncLock` 키워드를 제공한다.
  • 파이썬은 `threading` 모듈의 `Lock` 클래스를 통해 저수준 상호 배제 메커니즘을 제공한다.[19]
  • 루비는 저수준 상호 배제 객체를 제공하며, 별도 키워드는 없다.[21]
  • 에이다는 보호된 서브프로그램 또는 엔트리를 가진 보호 객체[7]와 랑데부[8]를 제공한다.
  • x86 어셈블리어는 `LOCK` 접두사를 사용하여 특정 연산의 원자성을 보장한다.
  • PHP는 파일 기반 잠금[17]과 `pthreads` 확장 기능의 `Mutex` 클래스를 제공한다.[18]
  • ISO/IEC 포트란 표준 (ISO/IEC 1539-1:2010)은 Fortran 2008부터 내장 모듈 `iso_fortran_env`에서 `lock_type` 파생 형식과 `lock`/`unlock` 문을 제공한다.[20]
  • 러스트는 `Mutex`[22] 구조체를 제공한다.[23]
  • 하스켈은 `MVar`라는 변경 가능한 데이터 구조를 통해 잠금을 구현한다. `MVar`는 비어 있거나 리소스 참조 값을 포함할 수 있다. 리소스 사용 스레드는 `MVar` 값을 가져와 비워두고, 작업 완료 후 다시 채운다. 빈 `MVar`에서 리소스를 가져오려는 시도는 스레드를 블록시킨다.[24] 소프트웨어 트랜잭션 메모리 구현도 잠금 대안으로 존재한다.[25]
  • Go는 표준 라이브러리의 [https://pkg.go.dev/sync sync] 패키지에서 저수준 Mutex 객체를 제공하며,[26] 코드 블록, 메서드, 객체 잠금에 사용 가능하다.
  • ISO/IEC C 표준은 C11부터 표준 상호 배제 (잠금) API를 제공한다. C++ 표준은 쓰레딩 기능을 C++11부터 지원한다. OpenMP는 일부 컴파일러에서 지원되며, 프라그마를 통해 임계 구역을 지정한다. POSIX pthread API는 잠금을 지원한다.[9] Visual C++는 `synchronize` 속성을 제공하지만, Windows 및 Visual C++ 컴파일러의 COM 객체에 한정된다.[10] C와 C++는 모든 네이티브 운영 체제 잠금 기능에 쉽게 접근할 수 있다.

3. 1. C# 예제

C#은 .NET 9의 C# 13에서 `System.Threading.Lock`을 도입했다.

다음은 C#의 락 사용 예시이다.[1]

```csharp

public class Account // This is a monitor of an account

{

// Use `object` in versions earlier than C# 13

private readonly Lock _balanceLock = new();

private decimal _balance = 0;

public void Deposit(decimal amount)

{

// Only one thread at a time may execute this statement.

lock (_balanceLock)

{

_balance += amount;

}

}

public void Withdraw(decimal amount)

{

// Only one thread at a time may execute this statement.

lock (_balanceLock)

{

_balance -= amount;

}

}

}

```

위 코드에서 `lock(this)`는 인스턴스에 공개적으로 액세스할 수 있는 경우 문제를 일으킬 수 있다.[1]

자바 (프로그래밍 언어)와 유사하게 C#은 `MethodImplOptions.Synchronized` 특성을 사용하여 전체 메서드를 동기화할 수도 있다.[2][3]

```csharp

[MethodImpl(MethodImplOptions.Synchronized)]

public void SomeMethod()

{

// do stuff

}

3. 2. Java 예제

이러한 주요 잠금 유형에는 여러 변형과 개선 사항이 존재하며, 각기 다른 차단 동작을 보인다. 첫 번째 잠금이 다른 잠금을 차단하는 경우, 두 잠금은 ''호환되지 않는다''고 하며, 그렇지 않은 경우 잠금은 ''호환된다''고 한다. 종종, 잠금 유형의 상호 작용 차단은 기술 문헌에서 ''잠금 호환성 테이블''로 표현된다. 다음은 일반적인 주요 잠금 유형의 예이다.

잠금 호환성 테이블
잠금 유형읽기 잠금쓰기 잠금
읽기 잠금✔X
쓰기 잠금XX


  • '''✔'''는 호환성을 나타낸다.
  • '''X'''는 비호환성을 나타낸다. 즉, 첫 번째 유형(왼쪽 열)의 잠금이 동일한 개체에서 두 번째 유형(상단 행)의 잠금이 획득되는 것을 차단하는 경우이다(다른 트랜잭션에 의해). 일반적으로 개체는 각 잠금이 있는 대기 중인 요청된(트랜잭션별) 작업 큐를 가진다. 큐에서 작업에 대한 첫 번째 차단된 잠금은 기존 차단 잠금이 개체에서 제거되는 즉시 획득된 다음, 해당 작업이 실행된다. 큐에서 작업에 대한 잠금이 기존 잠금에 의해 차단되지 않으면(동일한 개체에서 여러 개의 호환 잠금이 동시에 존재하는 것이 가능함), 즉시 획득된다.

일부 출판물에서는 테이블 항목이 단순히 "호환" 또는 "비호환"으로 표시되거나 각각 "예" 또는 "아니오"로 표시된다.[5]

4. 데이터베이스 락

데이터베이스 락은 여러 트랜잭션이 동시에 데이터베이스에 접근할 때 데이터의 일관성과 무결성을 유지하기 위해 사용되는 기술이다. 데이터베이스 관리 시스템(DBMS)은 락을 사용하여 트랜잭션 동기화를 보장하고, 2단계 잠금과 같은 방법을 통해 트랜잭션의 동시 실행이 직렬화된 순서와 동일한 결과를 갖도록 한다.

데이터베이스 락은 교착 상태를 유발할 수 있다는 단점이 있다. 교착 상태는 트랜잭션 간의 잠금 순서를 미리 정하거나 대기 그래프를 사용하여 감지하고 해결할 수 있다. 또는, 완전히 정렬된 글로벌 타임스탬프를 사용하여 교착 상태를 예방할 수도 있다.

데이터베이스 락은 크게 비관적 락과 낙관적 락으로 나뉜다.

4. 1. 락의 종류

데이터베이스 락은 여러 사용자가 동시에 데이터베이스에 접근할 때 발생할 수 있는 문제를 해결하기 위해 사용되는 기술이다. 크게 비관적 락과 낙관적 락 두 가지 종류가 있다.

  • '''비관적 락 (Pessimistic Lock):''' 한 사용자가 데이터를 수정하기 위해 읽을 때, 다른 사용자가 해당 데이터를 수정하거나 읽지 못하도록 '''배타적 락'''을 건다. 락을 획득한 사용자가 락을 해제할 때까지 다른 사용자는 해당 데이터에 접근할 수 없다. 데이터 충돌을 확실하게 방지할 수 있지만, 락이 오랫동안 유지될 수 있어 시스템 전체의 응답 속도가 느려질 수 있다. 데이터 경쟁이 치열하고, 락을 사용하여 데이터를 보호하는 비용이 트랜잭션을 롤백하는 비용보다 낮은 경우에 적합하며, 락을 유지하는 시간은 짧을수록 좋다.

  • '''낙관적 락 (Optimistic Lock):''' 여러 사용자가 동시에 데이터베이스에 접근하는 것을 허용하지만, 각 사용자는 처음에 읽은 데이터의 사본을 보관한다. 사용자가 데이터를 수정하려고 할 때, 애플리케이션은 해당 데이터가 마지막으로 읽힌 이후 다른 사용자에 의해 변경되었는지 확인한다. 변경되지 않았다면 수정을 허용하고, 변경되었다면 수정을 거부하고 사용자에게 오류 메시지를 보낸 후 업데이트를 다시 시도하도록 한다. 락을 사용하는 시간을 최소화하여 데이터베이스 성능을 향상시키지만, 여러 사용자가 동시에 수정을 시도하는 경우 잦은 업데이트 실패가 발생할 수 있다. 데이터 경쟁이 적거나, 데이터에 대한 읽기 전용 접근이 많은 경우에 적합하다. 특히, .NET 환경에서 장기간 락 유지가 어려운 모바일 애플리케이션 등에서 자주 사용된다.[34]


락의 종류 비교
구분비관적 락낙관적 락
락 설정 시점데이터를 읽을 때데이터를 읽을 때는 락을 설정하지 않음
락 유지데이터를 수정하는 동안 락 유지데이터를 수정하기 직전에만 락을 잠깐 사용
장점데이터 충돌 완벽 방지데이터베이스 성능 향상
단점시스템 응답 속도 저하 가능성잦은 업데이트 실패 가능성
적합한 환경데이터 경쟁이 치열한 환경데이터 경쟁이 적은 환경


5. 락의 문제점

락은 여러 스레드가 동시에 공유 자원에 접근할 때 발생할 수 있는 문제를 해결하기 위한 중요한 도구이지만, 몇 가지 잠재적인 문제점을 가지고 있다.


  • 교착 상태 (Deadlock): 둘 이상의 스레드나 프로세스가 서로 락을 기다리며 무한정 대기하는 현상이다. 예를 들어, 스레드 A가 락 1을 획득하고 락 2를 기다리는 동안, 스레드 B가 락 2를 획득하고 락 1을 기다리는 상황이 발생하면 두 스레드 모두 영원히 진행할 수 없게 된다.[6] 이러한 교착 상태는 락의 경합과 관련이 있으며, 락의 수를 늘릴수록 교착 상태의 위험성도 증가한다.
  • 기아 상태 (Starvation): 특정 스레드나 프로세스가 락을 획득하지 못하고 계속 대기하는 현상이다. 우선순위가 낮은 스레드가 락을 획득하기 어려운 상황에서 주로 발생한다.
  • 우선순위 역전 (Priority Inversion): 낮은 우선순위의 스레드가 락을 가진 채로 높은 우선순위의 스레드를 블록시키는 현상이다. 이로 인해 시스템의 전반적인 성능이 저하될 수 있다.


락 기반 프로그래밍의 또 다른 문제는 "락이 조합되지 않는다"는 것이다. 즉, 작고 정확한 락 기반 모듈을 결합하여 더 큰 프로그램을 만들 때, 모듈을 수정하거나 내부 구조를 알아야만 정확성을 보장할 수 있다.[6]

이러한 문제점들을 해결하기 위해 다양한 전략들이 사용된다. 예를 들어, 락 획득 순서를 표준화하여 교착 상태를 방지하거나, 락 대신 블로킹하지 않는 동기화 기법을 사용하는 방법 등이 있다. 하지만 이러한 기법들도 락과 관련된 문제를 완전히 해결하지는 못한다.

6. 락의 대안

락 기반 프로그래밍은 여러 스레드가 공유 자원에 접근할 때 발생할 수 있는 문제들을 해결하기 위해 사용되지만, 몇 가지 단점과 한계점을 가지고 있다. 이러한 문제점을 해결하기 위해 락을 사용하지 않는 대안적인 동기화 기법들이 연구 및 개발되고 있다.


  • 락의 문제점:
  • 교착 상태(Deadlock): 둘 이상의 스레드가 서로 상대방이 점유하고 있는 락을 기다리면서 무한정 대기하는 상태가 발생할 수 있다.
  • 라이브락(Livelock): 스레드들이 서로 양보만 하다가 락을 획득하지 못하고 계속해서 락 획득 시도를 반복하는 현상이다.
  • 우선순위 역전(Priority Inversion): 낮은 우선순위의 스레드가 락을 점유하고 있을 때, 높은 우선순위의 스레드가 해당 락을 기다리느라 지연되는 현상이다.
  • 성능 저하: 락을 획득하고 해제하는 과정에서 오버헤드가 발생하며, 락 경쟁이 심한 경우 성능 저하가 발생할 수 있다.
  • 복잡성: 락 기반 프로그래밍은 복잡하며, 특히 여러 개의 락을 사용하는 경우 교착 상태를 피하기 위한 설계가 어렵다.
  • 조합 불가 (Non-compositional): 락 기반 모듈은 조합하기 어렵다. 즉, 작고 정확한 락 기반 모듈을 결합하여 크고 정확한 프로그램을 만들기 어렵다.[6]


이러한 문제점들을 극복하기 위해 다음과 같은 락의 대안들이 제시되고 있다.

  • 락-프리(Lock-Free) 프로그래밍:

락을 사용하지 않고, 원자적 연산 (예: compare-and-swap)을 사용하여 공유 자원에 대한 접근을 동기화하는 기법이다. 락-프리 프로그래밍은 교착 상태나 우선순위 역전과 같은 문제를 방지할 수 있지만, 구현이 복잡하고 모든 상황에 적용하기는 어렵다.

  • 소프트웨어 트랜잭션 메모리(Software Transactional Memory, STM):

데이터베이스 트랜잭션 개념을 메모리 접근에 적용하여 동기화를 수행하는 기법이다. STM은 프로그래머가 트랜잭션 블록 내에서 공유 자원에 대한 연산을 수행하면, 시스템이 자동으로 동시성을 관리하고 충돌을 감지하여 필요한 경우 연산을 롤백한다. STM은 락 기반 프로그래밍보다 사용하기 쉽고 교착 상태를 방지할 수 있지만, 성능 오버헤드가 발생할 수 있다.

7. 세분성(Granularity)

락의 세분성은 락이 보호하는 데이터의 양을 나타내는 척도이다. 락 세분성을 논하기 전에, 다음 세 가지 개념을 이해해야 한다.


  • 락 오버헤드: 락 사용에 따른 추가적인 자원 소모를 의미한다. 여기에는 락에 할당되는 메모리 공간, 락 초기화 및 파괴에 필요한 CPU 시간, 락 획득 및 해제에 걸리는 시간 등이 포함된다. 프로그램에서 락을 많이 사용할수록 오버헤드는 커진다.
  • 락 자원 경합: 한 프로세스 또는 스레드가 다른 프로세스 또는 스레드가 이미 보유하고 있는 락을 획득하려 할 때 발생한다. 락의 세분성이 세밀할수록, 한 프로세스/스레드가 다른 프로세스/스레드가 보유한 락을 요청할 가능성이 줄어든다. 예를 들어, 전체 테이블 대신 행을 잠그거나, 전체 행 대신 셀을 잠그는 경우가 이에 해당한다.
  • 교착 상태: 최소 두 개의 작업이 서로 다른 작업이 가지고 있는 락을 기다리는 상황을 말한다. 특별한 조치가 취해지지 않는 한, 두 작업은 영원히 서로를 기다리게 된다.


동기화 시 락의 수를 선택할 때는 락 오버헤드를 줄이는 것과 락 경합을 줄이는 것 사이에 상충 관계가 존재한다.

일반적으로, 굵은 세분성(coarse granularity)은 적은 수의 락을 사용하며, 각 락은 많은 양의 데이터를 보호한다. 이러한 경우 단일 프로세스가 보호된 데이터에 접근할 때 락 오버헤드는 줄어들지만, 여러 프로세스가 동시에 실행될 때는 락 경합이 증가하여 성능이 저하된다. 락이 굵을수록 관련 없는 프로세스가 진행을 멈추게 할 가능성이 높아지기 때문이다.

반대로, 세밀한 세분성(fine granularity)은 더 많은 수의 락을 사용하며, 각 락은 비교적 적은 양의 데이터를 보호한다. 이 경우 락 자체의 오버헤드는 증가하지만 락 경합은 줄어든다. 각 프로세스가 공통 락 집합에서 여러 락을 보유해야 하는 세분화된 락킹은 미묘한 락 종속성을 만들 수 있으며, 프로그래머가 자신도 모르게 교착 상태를 발생시킬 가능성을 높일 수 있다.

예를 들어, 데이터베이스 관리 시스템에서 락은 세분성이 감소하는 순서대로 필드의 일부, 필드, 레코드, 데이터 페이지 또는 전체 테이블을 보호할 수 있다. 테이블 락과 같은 굵은 세분성은 단일 사용자 환경에서 최고의 성능을 제공하는 경향이 있는 반면, 레코드 락과 같은 세밀한 세분성은 여러 사용자 환경에서 최고의 성능을 제공하는 경향이 있다.

참조

[1] 웹사이트 lock Statement (C# Reference) http://msdn.microsof[...] 2013-02-04
[2] 웹사이트 ThreadPoolPriority, and MethodImplAttribute http://msdn.microsof[...] MSDN 2011-11-22
[3] 웹사이트 C# From a Java Developer's Perspective http://www.25hoursad[...] 2011-11-22
[4] 웹사이트 Designing Data Tier Components and Passing Data Through Tiers http://msdn.microsof[...] Microsoft 2002-08
[5] 웹사이트 Lock Based Concurrency Control Protocol in DBMS https://www.geeksfor[...] 2023-12-28
[6] encyclopedia Beautiful concurrency http://research.micr[...] O'Reilly
[7] 서적 Ada 2005 Reference Manual 2010-02-27
[8] 서적 Ada 2005 Reference Manual 2010-02-27
[9] 웹사이트 Mutual Exclusion Locks http://www.cs.cf.ac.[...] 1999-03
[10] 웹사이트 Synchronize http://msdn.microsof[...] msdn.microsoft.com
[11] 웹사이트 Synchronization http://java.sun.com/[...] Sun Microsystems
[12] 웹사이트 Apple Threading Reference https://developer.ap[...] Apple, inc
[13] 웹사이트 NSLock Reference https://developer.ap[...] Apple, inc
[14] 웹사이트 NSRecursiveLock Reference https://developer.ap[...] Apple, inc
[15] 웹사이트 NSConditionLock Reference https://developer.ap[...] Apple, inc
[16] 웹사이트 NSLocking Protocol Reference https://developer.ap[...] Apple, inc
[17] 웹사이트 flock http://php.net/manua[...]
[18] 웹사이트 The Mutex class http://php.net/manua[...] 2016-12-29
[19] 웹사이트 Thread Synchronization Mechanisms in Python http://effbot.org/zo[...] 2007-07
[20] 웹사이트 Coarrays in the next Fortran Standard https://wg5-fortran.[...] 2020-02-17
[21] 웹사이트 Programming Ruby: Threads and Processes http://www.ruby-doc.[...]
[22] 웹사이트 std::sync::Mutex - Rust https://doc.rust-lan[...] 2020-11-03
[23] 웹사이트 Shared-State Concurrency - The Rust Programming Language https://doc.rust-lan[...] 2020-11-03
[24] 서적 Parallel and Concurrent Programming in Haskell https://www.oreilly.[...] O’Reilly Media 2013-08
[25] 서적 Parallel and Concurrent Programming in Haskell https://www.oreilly.[...] O’Reilly Media 2013-08
[26] 웹사이트 sync package - sync - pkg.go.dev https://pkg.go.dev/s[...] 2021-11-23
[27] 문서 threading — Thread-based parallelism — Python 3.12.4 documentation https://docs.python.[...]
[28] 문서 lock ステートメント - 共有リソースへのアクセスを同期 - C# reference | Microsoft Learn https://learn.micros[...]
[29] 문서 lock Statement (C# Reference) | Microsoft Learn https://learn.micros[...]
[30] 문서 マルチスレッド - C# によるプログラミング入門 | ++C++; // 未確認飛行 C https://ufcpp.net/st[...]
[31] 문서 .NET Matters: ThreadPoolPriority, and MethodImplAttribute | Microsoft Learn https://learn.micros[...]
[32] 웹사이트 C# From a Java Developer's Perspective http://www.25hoursad[...] 2011-11-22
[33] 문서 MethodImplOptions Enum (System.Runtime.CompilerServices) | Microsoft Learn https://learn.micros[...]
[34] 웹사이트 Designing Data Tier Components and Passing Data Through Tiers http://msdn.microsof[...] Microsoft 2002-08
[35] 웹사이트 Mutual Exclusion Locks http://www.cs.cf.ac.[...] 1999-03
[36] 웹사이트 Critical Section Objects - Win32 apps | Microsoft Learn https://learn.micros[...]
[37] 웹사이트 Mutex Objects - Win32 apps | Microsoft Learn https://learn.micros[...]
[38] 웹사이트 Synchronization Objects - Win32 apps | Microsoft Learn https://learn.micros[...]
[39] 웹사이트 lock_guard - cpprefjp C++日本語リファレンス https://cpprefjp.git[...]
[40] 웹사이트 CSingleLock Class | Microsoft Learn https://learn.micros[...]
[41] 웹사이트 Synchronize http://msdn.microsof[...] msdn.microsoft.com 2008-05-30
[42] 웹사이트 Synchronization (The Java™ Tutorials > Essential Java Classes > Concurrency) https://docs.oracle.[...]
[43] 웹사이트 Javaにおける同期（パート2）：synchronizedキーワード https://blogs.oracle[...]
[44] 웹사이트 Thread Synchronization Mechanisms in Python http://effbot.org/zo[...] 2007-07
[45] 웹사이트 Programming Ruby: Threads and Processes http://www.ruby-doc.[...]
[46] 웹사이트 Apple Threading Reference http://developer.app[...] Apple, inc 2009-10-17
[47] 웹사이트 NSLock Reference http://developer.app[...] Apple, inc 2009-10-17
[48] 웹사이트 NSRecursiveLock Reference http://developer.app[...] Apple, inc 2009-10-17
[49] 웹사이트 NSConditionLock Reference http://developer.app[...] Apple, inc 2009-10-17
[50] 웹사이트 NSLocking Protocol Reference http://developer.app[...] Apple, inc 2009-10-17
[51] 웹인용 "'잠금': 네이버 국어사전" https://ko.dict.nave[...] 네이버 국어사전 2022-03-10


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com