선물과 약속

Futures and promises
Promise 이론과 혼동하지 말 것.

컴퓨터 과학에서 미래, 약속, 지연 및 지연은 일부 동시 프로그래밍 언어에서 프로그램 실행을 동기화하기 위해 사용되는 구조를 말합니다.일반적으로 값의 계산이 아직 완료되지 않았기 때문에 처음에는 알 수 없는 결과의 프록시 역할을 하는 개체를 설명합니다.

약속이라는 용어는 1976년 다니엘 P에 의해 제안되었다. 프리드먼과 데이비드 [1]와이즈 그리고 피터 히바드는 그것을 [2]궁극적이라 불렀다.다소 비슷한 개념의 미래는 1977년 헨리 베이커와 칼 [3]휴이트의 논문에서 소개되었다.

미래, 약속, 지연 및 지연이라는 용어는 종종 서로 바꿔서 사용되지만 미래와 약속 간의 사용 차이는 다음과 같습니다.구체적으로 용도가 구별되는 경우 미래는 변수의 읽기 전용 플레이스홀더 뷰이며 약속은 미래의 가치를 설정하는 쓰기 가능한 단일 할당 컨테이너입니다.특히, 미래는 어떤 특정 약속이 그 가치를 설정할지 명시하지 않고 정의될 수 있으며, 다른 가능한 약속들은 주어진 미래에 대해 한 번만 수행될 수 있지만, 주어진 미래의 가치를 설정할 수 있다.다른 경우에는 미래와 약속이 함께 생성되어 서로 관련지어집니다.미래는 가치, 약속은 가치를 설정하는 기능, 즉 기본적으로 비동기 기능(약속)의 리턴 값(미래)입니다.미래의 가치를 설정하는 것을 해결, 충족 또는 구속이라고도 합니다.

적용들

미래와 약속은 값(미래)을 계산 방법(약속)에서 분리하는 기능 프로그래밍 및 관련 패러다임(로직 프로그래밍 등)에서 비롯되며, 특히 병렬화함으로써 계산을 보다 유연하게 수행할 수 있습니다.이후 분산 컴퓨팅에서 통신 왕복의 지연 시간을 줄이는 데 활용되었습니다.나중에, 그것은 연속 전달 방식이 아닌 직접 방식으로 비동기식 프로그램을 작성할 수 있게 함으로써 더 많은 활용도를 얻었다.

암묵적 vs. 명시적

선물 사용은 암묵적(미래의 모든 사용은 일반적인 참조인 것처럼 자동으로 가치를 획득함) 또는 명시적(사용자는 값을 얻기 위해 함수를 호출해야 함)일 수 있습니다.get의 방법java.util.concurrent.Future(Java).명확한 미래의 가치를 얻는 것은 따끔따끔함 또는 강요라고 할 수 있다.명시적 미래는 라이브러리로 구현될 수 있지만 암묵적 미래는 보통 언어의 일부로 구현됩니다.

원래 Baker와 Hewitt의 논문은 암묵적인 미래를 설명했는데, 이는 자연스럽게 연산 모델 및 Smalltalk와 같은 순수한 객체 지향 프로그래밍 언어에서 지원됩니다.Friedman과 Wise의 논문은 명시적인 선물만을 설명했는데, 이는 아마도 주식 하드웨어에 암묵적인 선물을 효율적으로 구현하는 것의 어려움을 반영했을 것이다.문제는 주식 하드웨어가 정수와 같은 원시 데이터 유형의 미래를 다루지 않는다는 것입니다.예를 들어, 추가 명령이 다음 명령을 처리하는 방법을 알지 못합니다.3 + future factorial(100000)순수 행위자 또는 객체 언어에서는 이 문제를 다음 주소로 전송하여 해결할 수 있습니다.future factorial(100000)메시지+[3]장래에 추가할 것을 요구합니다.3결과를 반환할 수 있습니다.메시지 전달 접근법은 다음 경우에 관계없이 기능합니다.factorial(100000)가 계산을 완료하고 따끔따끔한 소리나 비난이 필요 없습니다.

약속 파이프라인

미래를 사용하면 분산 시스템에서 대기 시간을 크게 줄일 수 있습니다.예를 들어, Future는 E [4][5]및 Joule 언어로 구현된 약속 파이프링을 활성화합니다.이것은 Argus 언어에서는 call-stream이라고도[6] 불립니다.

기존의 리모트프로시저 콜을 수반하는 표현에 대해 생각해 봅시다.예를 들어 다음과 같습니다.

t3 : = ( x . a ) . c ( y . b )

더 확장될 수 있다

t1 := x.a(); t2 := y.b(); t3 := t1.c(t2);

각 스테이트먼트는 다음 스테이트먼트를 진행하기 전에 메시지를 전송하고 응답을 받아야 합니다.예를 들어 다음과 같이 가정합니다.x,y,t1,그리고.t2모두 같은 리모트머신에 배치되어 있습니다.이 경우 세 번째 문의 실행을 시작하기 전에 해당 머신에 대한 네트워크 라운드 트립을 2회 완료해야 합니다.세 번째 스테이트먼트에 의해 같은 리모트머신으로의 또 다른 라운드 트립이 발생합니다.

선물을 사용하여 위의 식을 작성할 수 있습니다.

t3 : = (x <- a()) <- c(y <- b())

더 확장될 수 있다

t1 : = x < - a ( ) ; t2 : = y < - b ( ) ; t3 : = t1 < - c ( t2) ;

여기서 사용되는 구문은 E 언어의 구문입니다.x <- a()메시지를 보내는 수단a()와 비동기적으로x3가지 변수 모두 결과에 대해 즉시 미래를 할당하고 실행은 후속 문장으로 진행됩니다.나중에 값을 해결하려고 합니다.t3는 지연의 원인이 될 수 있지만 파이프라이닝을 통해 필요한 라운드 스위칭의 수를 줄일 수 있습니다.앞의 예시와 같이x,y,t1,그리고.t2모두 같은 리모트 머신에 배치되어 있기 때문에 파이프라인 실장에서는t3왕복 3회 대신 왕복 1회로요.3개의 메시지는 모두 같은 리모트머신상의 오브젝트 앞으로 송신되기 때문에, 송신되는 요구는 1개뿐이며, 그 결과를 포함한 응답은 1개뿐입니다.송신t1 <- c(t2)해도 막지 않는다t1그리고.t2서로 다른 기계를 타고 있었거나x또는y.

약속 파이프라인은 병렬 비동기 메시지 전달과 구별되어야 합니다.병렬 메시지 전달을 지원하지만 파이프라인은 지원하지 않는 시스템에서는 메시지가x <- a()그리고.y <- b()위의 예에서는 병렬로 진행할 수 있지만,t1 <- c(t2)둘 다 기다릴 필요가 있다t1그리고.t2받은 적이 있다, 심지어x,y,t1,그리고.t2같은 리모트 머신상에 있습니다.파이프라인의 상대적인 지연의 이점은 많은 메시지가 포함된 복잡한 상황에서 더욱 커집니다.

또한 약속 파이프라인은 액터 시스템에서 파이프라인 메시지 처리와 혼동해서는 안 됩니다.액터 시스템에서는 액터가 현재 메시지의 처리를 완료하기 전에 다음 메시지에 대한 동작을 지정하고 실행을 시작할 수 있습니다.

읽기 전용 보기

Oz, E, AmbientTalk 등의 일부 프로그래밍 언어에서는 미래에 대한 읽기 전용 뷰를 얻을 수 있습니다.이 뷰는 해결 시 값을 읽을 수 있지만 해결은 허용하지 않습니다.

  • 오즈에서는!!연산자는 읽기 전용 보기를 얻기 위해 사용됩니다.
  • E와 AmbientTalk에서는 미래는 약속/해결자 쌍이라고 불리는 값의 쌍으로 나타납니다.약속은 읽기 전용 보기를 나타내며 미래의 가치를 설정하려면 해결사가 필요합니다.
  • C++11 a에서는std::future는 읽기 전용 뷰를 제공합니다.값은 를 사용하여 직접 설정됩니다.std::promise또는 를 사용하여 함수 호출의 결과로 설정합니다.std::packaged_task또는std::async.
  • Dojo Toolkit의 Deferred API 버전 1.5에서 소비자 전용 약속 개체는 읽기 전용 [7]보기를 나타냅니다.
  • 앨리스 ML에서 미래는 읽기 전용 뷰를 제공하는 반면 약속은 미래와 미래를[8][9] 해결할 수 있는 능력을 모두 포함합니다.
  • .NET Framework 4.0의 경우 System.Threading.Tasks.Task<T>는 읽기 전용 뷰를 나타냅니다.이 값을 해결하려면System.Threading.Tasks.TaskCompletionSource<T>.

읽기 전용 뷰의 서포트는, 값을 설정할 필요가 있는 서브젝트로 제한할 수 있기 때문에, 최소 특권의 원칙에 준거하고 있습니다.파이프라인도 지원하는 시스템에서 비동기 메시지(결과 포함)의 송신자는 결과에 대한 읽기 전용 약속을 수신하고 메시지의 타깃은 리졸버를 수신한다.

스레드 고유의 선물

Alice ML과 같은 일부 언어는 미래의 [9]가치를 계산하는 특정 스레드와 관련된 미래를 정의합니다.이 계산은 미래를 창조할 때 열심히 시작하거나 그 가치가 처음 필요할 때 느릿느릿 시작할 수 있다.게으른 미래는 연산이 늦어진다는 의미에서 덩크와 비슷하다.

또한 Alice ML은 임의의 스레드로 해결할 수 있는 미래를 지원하며 이러한 [8]약속을 호출합니다.이러한 약속의 사용은 위에서 설명한 바와 같이 E에서의 사용과는 다릅니다.앨리스에서 약속은 읽기 전용 뷰가 아니며 약속 파이프라인은 지원되지 않습니다.대신, 파이프라인은 약속과 관련된 미래를 포함하여 자연스럽게 발생합니다.

블로킹과 비블로킹의 의미

미래 값에 비동기적으로 액세스하는 경우(예: 메시지를 전송하거나 다음과 같은 구성을 사용하여 미래 값을 명시적으로 기다리는 경우)whenE에서는 메시지를 수신하거나 대기 시간이 완료될 때까지 미래를 해결할 때까지 지연하는 것은 어렵지 않습니다.이것은 순수 행위자 언어와 같은 순수 비동기 시스템에서 고려되는 유일한 경우입니다.

그러나 일부 시스템에서는 미래의 가치에 즉시 또는 동기적으로 액세스하려고 시도할 수도 있습니다.다음으로 설계 선택을 할 수 있습니다.

  • 액세스에 의해, 장래가 해결될 때까지(타임 아웃이 있는 경우는 제외) 현재의 스레드 또는 프로세스가 차단될 가능성이 있습니다.이것은 Oz 언어로 된 데이터 흐름 변수의 의미입니다.
  • 동기 액세스를 시도하면 예외 발생 등의 오류가 항상 발생할 수 있습니다.이것은 [10]E에서의 리모트 약속의 의미입니다.
  • 장래가 이미 해결된 경우에는 액세스가 성공할 수 있지만, 해결되지 않은 경우에는 에러를 통지할 수 있습니다.이것은 비결정주의나 인종 조건의 가능성을 도입하는 단점이 있어, 흔치 않은 설계 선택인 것 같다.

첫 번째 가능성의 예로서 C++11에서는 미래의 값을 필요로 하는 스레드는 다음 명령어를 호출하여 사용할 수 있을 때까지 차단할 수 있습니다.wait()또는get()멤버 함수대기시간 타임아웃을 지정할 수도 있습니다.wait_for()또는wait_until()member 함수는 무기한 차단을 회피합니다.만약 미래가 ...에 대한 요구에서 비롯되었다면std::async그러면 (타임아웃 없이) 블로킹 대기 상태가 되면 함수가 동기 호출되어 대기 스레드 상의 결과가 계산될 수 있습니다.

관련 구성

선물은 한 번만 완료할 수 있는 동기화 프리미티브 "이벤트"의 특별한 경우입니다.일반적으로 이벤트는 초기 빈 상태로 리셋할 수 있으므로 원하는 [11]횟수만큼 완료할 수 있습니다.

I-var(언어 Id와 같이)는 위에서 정의한 블로킹시멘틱스를 가진 미래입니다I-structure는 I-vars를 포함하는 데이터 구조입니다.다른 값을 사용하여 여러 번 설정할 수 있는 관련 동기화 구성을 M-var라고 합니다.M-vars는 현재 값을 가져오거나 설정하는 원자 연산을 지원합니다.이 값을 사용하면 M-var도 초기 빈 [12]상태로 돌아갑니다.

동시 논리[citation needed] 변수는 미래와 유사하지만 논리 프로그래밍의 논리 변수와 같은 방식으로 통일에 의해 업데이트됩니다.따라서 이 값은 여러 번 바인딩할 수 있지만 빈 상태 또는 해결되지 않은 상태로 되돌릴 수 없습니다.Oz의 데이터 흐름 변수는 동시 논리 변수로서 작용하며, 위와 같이 블로킹 의미론도 가지고 있다.

동시 제약 변수는 제약 논리 프로그래밍을 지원하기 위한 동시 논리 변수의 일반화입니다. 제약 조건은 여러 번 좁혀질 수 있으며 가능한 값의 더 작은 집합을 나타낼 수 있습니다.통상, 제약이 한층 더 좁혀질 때마다 실행할 필요가 있는 트렁크를 지정하는 방법이 있습니다.이것은 제약의 전파를 서포트하기 위해서 필요합니다.

다양한 형태의 미래 표현력 간의 관계

스레드 고유의 미래를 빠르게 구현하려면 스레드 고유의 미래를 만드는 동시에 값을 계산하는 스레드를 작성해야 합니다.이 경우 새로 생성된 스레드만 이 미래를 해결할 수 있도록 읽기 전용 뷰를 클라이언트에 반환하는 것이 좋습니다.

비 스레드 고유의 미래에서 암묵적인 게으른 스레드 고유의 미래(예를 들어 Alice ML에 의해 제공됨)를 구현하려면 미래의 가치가 언제 최초로 필요한지 결정하는 메커니즘이 필요합니다(예를 들어,WaitNeeded(Oz)로[13] 구축합니다.모든 값이 객체인 경우 Forwarder로 전송되는 첫 번째 메시지가 미래의 값이 필요하다는 것을 나타내므로 투명 전달 개체를 구현하는 기능만으로도 충분합니다.

스레드 고유의 미래에는 시스템이 메시지 전달을 지원한다고 가정하고 해결 스레드가 미래의 스레드에 메시지를 보내도록 함으로써 스레드 고유의 미래에서 구현될 수 있습니다.그러나 이는 불필요한 복잡성으로 볼 수 있다.스레드에 기반한 프로그래밍 언어에서는 스레드 고유의 미래, 읽기 전용 뷰 및 WaitNeeded 구성 또는 투과적 포워딩 지원을 혼합하여 제공하는 것이 가장 표현적인 접근법인 것 같습니다.

평가 전략

상세정보: 미래로 전화

미래에 의한 호출이라고 할 수 있는 선물 평가 전략은 결정적이지 않다.미래의 가치는 미래를 창조한 시점과 그 가치를 사용한 시점 사이에 평가되지만, 정확한 시간은 사전에 결정되지 않고 실행에서 실행으로 변경될 수 있다.계산은 미래 생성 즉시(시력 평가) 또는 값이 실제로 필요한 경우에만 시작할 수 있으며(느긋한 평가) 중간에 중단되거나 한 번의 실행으로 실행될 수 있습니다.미래 값이 할당되면 미래 접근 시 재계산되지 않습니다.이것은 필요에 따라 콜에서 사용되는 메모와 같습니다.

게으른 미래는 결정적으로 게으른 평가 의미론을 갖는 미래이다. 미래의 가치 계산은 필요에 의한 호출과 같이 가치가 처음 필요할 때 시작된다.게으른 미래는 기본적으로 게으르지 않은 평가 전략이 있는 언어에서 사용됩니다.예를 들어, C++11에서 이러한 게으른 미래는 통과함으로써 생성될 수 있습니다.std::launch::deferred에 대한 정책을 개시하다std::async값을 계산하는 함수와 함께.

행위자 모델에서의 미래 의미론

액터 모델에서는 폼의 표현future <Expression>에 대한 응답 방법에 의해 정의됩니다.Eval다음과 같이 환경E 및 고객C에게 메시지를 보냅니다.미래의 표현은 에 응답합니다.Eval고객 C에게 새로 생성된 배우 F(평가 응답의 프록시)를 전송함으로써 메시지를 보냅니다.<Expression>)를 송신과 동시에 반환값으로 합니다.<Expression>한 사람EvalE 환경 및 고객 C에 대한 메시지입니다.F 의 디폴트 동작은 다음과 같습니다.

  • F는 요구 R을 수신하면 평가에서 이미 응답(반환값 또는 느려진 예외 중 하나)을 받았는지 여부를 확인합니다.<Expression>다음과 같이 진행합니다.
    1. 이미 응답 V가 있는 경우
      • V가 반환 값인 경우 요청 R이 전송됩니다.
      • V가 예외인 경우 요청 R의 고객에게 전달됩니다.
    2. 아직 응답이 없는 경우 R은 F 내의 요구 큐에 저장됩니다.
  • F가 V가 평가로부터 응답을 수신하는 경우<Expression>V는 F에 저장되며,
    • V이 반환 값이면 대기 중인 모든 요청이 V로 전송됩니다.
    • V이 예외인 경우 대기 중인 각 요청의 고객에게 전달됩니다.

그러나 일부 선물은 더 큰 병렬성을 제공하기 위해 특별한 방법으로 요청을 처리할 수 있습니다.예를 들어 다음과 같은 식입니다.1 + future factorial(n)숫자처럼 행동할 새로운 미래를 만들 수 있다1+factorial(n)이 속임수가 항상 효과가 있는 것은 아닙니다.예를 들어 다음과 같은 조건식이 있습니다.

if m>future factorial(n) then print("bigger") else print("smaller")

장래가 될 때까지 보류하다factorial(n)요청에 응답했습니다.m그 자체보다 더 위대하다.

역사

미래 및/또는 약속 구성은 MultiLisp 및 Act 1과 같은 프로그래밍 언어로 처음 구현되었습니다.동시 논리 프로그래밍 언어에서 통신을 위한 논리 변수의 사용은 미래와 매우 유사했습니다.프롤로그에서 프리즈(Freeze)와 IC 프롤로그(IC Prolog)로 시작되었으며, 데이터로부터의 Relational Language, Concurrent Prolog, Guarded Horn pares(GHC), Parlog, Strand, Vulcan, Janus, Oz-Mozart, Flow Java 및 Alice ML의 단일 할당 i-var 프로그래밍 언어에 의한 진정한 동시 실행 프리미티브가 되었습니다.는 동시 로직 변수와 매우 유사합니다.

약속 파이프라이닝 기법(지연을 극복하기 위해 미래를 사용하는)은 1988년 [6]Barbara Liskov와 Liuba Shira에 의해 발명되었고, Mark S. Miller, Dean Tribble 및 Rob Jellinghouse에 의해 독립적으로 1989년 프로젝트 [14]Xanadu의 맥락에서 발명되었습니다.

약속이라는 용어는 Liskov와 Shira에 의해 만들어졌지만 현재는 거의 사용되지 않는 call-stream이라는 이름으로 파이프라인 메커니즘을 지칭했습니다.

Liskov와 Shira의 논문에서 기술된 설계와 Xanadu에서의 약속 파이프라인 구현은 모두 약속 값이 1등급이 아니라는 한계를 가지고 있었습니다. 즉, 약속 값은 직접 약속일 수 없습니다(따라서 이전에 주어진 약속 파이프라인의 예에서는 약속의 결과에 대한 약속을 사용합니다).e는 다른 사람에게 인수로 전송되며 콜 스트림 설계 또는 Xanadu 구현에서는 직접 표현되지 않습니다).약속과 콜스트림은 리스코프와 슈리라의 논문에 사용된 프로그래밍 언어인 아르고스의 [15]공개 릴리스에서는 구현되지 않은 것으로 보인다.아르고스 개발은 [16]1988년경에 중단되었다.약속 파이프라인의 Xanadu 구현은 1999년 Udanax[17] Gold의 소스 코드가 공개되었을 때만 공개되었으며 공개된 [18]문서에서는 설명되지 않았다.Joule 및 E에서의 이후의 실장은 완전히 퍼스트 클래스의 약속과 해결사를 지원합니다.

Act [19][20]시리즈를 포함한 몇몇 초기 액터 언어들은 병렬 메시지 전달과 파이프라인 메시지 처리를 모두 지원했지만 파이프라인 처리를 약속하지는 않았다(이러한 기능 중 마지막을 처음 두 가지에서 구현하는 것은 기술적으로 가능하지만 Act 언어가 그렇게 했다는 증거는 없다).

2000년 이후, 메시지 전달의 요청-응답 모델 때문에 사용자 인터페이스의 응답성 및 웹 개발에서의 사용으로 인해 미래와 약속에 대한 관심이 크게 되살아났다.몇몇 주류 언어들은 현재 미래와 약속에 대한 언어 지원을 가지고 있으며, 가장 눈에 띄게 대중화 되었다.FutureTask의 비동기/대기 구성에 대해 설명합니다.[21]NET 4.5(2010년 발표,[22][23] 2012년 출시)는 [25]주로 2007년까지 거슬러 올라가는 F#[24]의 비동기 워크플로우에서 영감을 받았습니다.이는 이후 다른 언어, 특히 Dart(2014),[26] Python(2015),[27] Hack(HHVM) 및 ECMAScript 7(JavaScript), Scala 및 C++(2011) 초안에 채택되었습니다.

구현 목록

일부 프로그래밍 언어는 직접 언어 지원 또는 표준 라이브러리에서 미래, 약속, 동시 논리 변수, 데이터 흐름 변수 또는 I-var를 지원합니다.

프로그래밍 언어별 미래 및 약속 관련 개념 목록

Promise 파이프라인도 지원하는 언어는 다음과 같습니다.

비표준 라이브러리 기반 미래 구현 목록

코루틴

선물은 코루틴[27] 또는 [102]발전기로 구현될 수 있으며, 그 결과 동일한 평가 전략(예를 들어 공동 멀티태스킹 또는 게으른 평가)을 얻을 수 있습니다.

채널

주요 기사:채널(프로그래밍)

미래는 채널에서 쉽게 구현할 수 있습니다. 미래는 하나의 요소 채널이며 약속은 채널에 전송하여 [103][104]미래를 실현하는 프로세스입니다.이를 통해 CSP 및 Go와 같은 채널을 지원하는 동시 프로그래밍 언어로 미래를 구현할 수 있습니다.평가뿐만 아니라 채널에서 읽어서 접근해야 하므로 결과적인 미래는 명확합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Friedman, Daniel; David Wise (1976). The Impact of Applicative Programming on Multiprocessing. International Conference on Parallel Processing. pp. 263–272.
    예비 버전:
  2. ^ Hibbard, Peter (1976). Parallel Processing Facilities. New Directions in Algorithmic Languages, (ed.) Stephen A. Schuman, IRIA, 1976.
  3. ^ Henry Baker; Carl Hewitt (August 1977). The Incremental Garbage Collection of Processes. Proceedings of the Symposium on Artificial Intelligence Programming Languages. ACM SIGPLAN Notices 12, 8. pp. 55–59. Archived from the original on 4 July 2008. Retrieved 13 February 2015.
  4. ^ Promise 파이프라인(erights.org)
  5. ^ C2 Wiki의 Promise 파이프라인
  6. ^ a b 바바라 Liskov, 류바 Shrira(1988년)."약속:언어 지원 효율적 비동기 절차 주인을 살리기 위해 위해 분산 시스템에서".프로그래밍 언어 설계 및 구현에 SIGPLAN '88 회의 회보, 아틀란타, 조지아, 미국.ACM.를 대신하여 서명함. 260–267. doi:10.1145/53990.54016.아이 에스비엔 0-89791-269-1.또한 ACMSIGPLAN Notices 23(7)에 발표되었습니다.
  7. ^ Robust promises with Dojo deferred, Site Pen, 3 May 2010
  8. ^ a b "Promise", Alice Manual, DE: Uni-SB, archived from the original on 8 October 2008, retrieved 21 March 2007
  9. ^ a b "Future", Alice manual, DE: Uni-SB, archived from the original on 6 October 2008, retrieved 21 March 2007
  10. ^ Promise, E rights
  11. ^ 500행 이하, A사의 「A Web Crawler With asyncio Coroutines」. Jesse Jiryu Davis와 Guido van Rossum은 다음과 같이 말합니다. "실장에는 비동기식이 사용됩니다.여기에 표시된 미래 대신 이벤트.차이점은 이벤트를 리셋할 수 있지만 미래 해결에서 보류로 되돌릴 수 없다는 것입니다."
  12. ^ Control Concurrent MVar, Haskell, archived from the original on 18 April 2009
  13. ^ WaitNeeded, Mozart Oz, archived from the original on 17 May 2013, retrieved 21 March 2007
  14. ^ Promise, Sunless Sea, archived from the original on 23 October 2007
  15. ^ Argus, MIT
  16. ^ Liskov, Barbara (26 January 2021), Distributed computing and Argus, Oral history, IEEE GHN
  17. ^ Gold, Udanax, archived from the original on 11 October 2008
  18. ^ Pipeline, E rights
  19. ^ Henry Lieberman (June 1981). "A Preview of Act 1". MIT AI memo 625. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  20. ^ Henry Lieberman (June 1981). "Thinking About Lots of Things at Once without Getting Confused: Parallelism in Act 1". MIT AI memo 626. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  21. ^ Goetz, Brian (23 November 2004). "Concurrency in JDK 5.0". IBM.
  22. ^ a b "Async in 4.5: Worth the Await – .NET Blog – Site Home – MSDN Blogs". Blogs.msdn.com. Retrieved 13 May 2014.
  23. ^ a b c "Asynchronous Programming with Async and Await (C# and Visual Basic)". Msdn.microsoft.com. Retrieved 13 May 2014.
  24. ^ Tomas Petricek (29 October 2010). "Asynchronous C# and F# (I.): Simultaneous introduction".
  25. ^ Don Syme; Tomas Petricek; Dmitry Lomov (21 October 2010). "The F# Asynchronous Programming Model, PADL 2011".
  26. ^ a b Gilad Bracha (October 2014). "Dart Language Asynchrony Support: Phase 1".
  27. ^ a b "PEP 0492 – Coroutines with async and await syntax".
  28. ^ Kenjiro Taura; Satoshi Matsuoka; Akinori Yonezawa (1994). "ABCL/f: A Future-Based Polymorphic Typed Concurrent Object-Oriented Language – Its Design and Implementation.". In Proceedings of the DIMACS workshop on Specification of Parallel Algorithms, number 18 in Dimacs Series in Discrete Mathematics and Theoretical Computer Science. American Mathematical Society. pp. 275–292. CiteSeerX 10.1.1.23.1161.
  29. ^ "Dart SDK dart async Completer".
  30. ^ "Task".
  31. ^ Steve Dekorte (2005). "Io, The Programming Language".
  32. ^ "Using promises". Mozilla Developer Network. Retrieved 23 February 2021.
  33. ^ "Making asynchronous programming easier with async and await". Mozilla Developer Network. Retrieved 23 February 2021.
  34. ^ Rich Hickey (2009). "changes.txt at 1.1.x from richhickey's clojure". GitHub.
  35. ^ "Future - Kotlin Programming Language".
  36. ^ Seif Haridi; Nils Franzen. "Tutorial of Oz". Mozart Global User Library. Archived from the original on 14 May 2011. Retrieved 12 April 2011.
  37. ^ Python 3.2 릴리즈
  38. ^ Python 3.5 릴리즈
  39. ^ "Parallelism with Futures". PLT. Retrieved 2 March 2012.
  40. ^ Perl 6에서의 Promise 클래스
  41. ^ "Future in STD::future - Rust".
  42. ^ 검은새
  43. ^ Lisp의 일반적인 미래2
  44. ^ Lisp in parallel – Common Lisp용 병렬 프로그래밍 라이브러리
  45. ^ 일반적인 리스프 PCall
  46. ^ "Chapter 30. Thread 4.0.0". Retrieved 26 June 2013.
  47. ^ "Dlib C++ Library #thread_pool". Retrieved 26 June 2013.
  48. ^ "GitHub – facebook/folly: An open-source C++ library developed and used at Facebook". GitHub. 8 January 2019.
  49. ^ "HPX". 10 February 2019.
  50. ^ "Threads Slides of POCO" (PDF).
  51. ^ "QtCore 5.0: QFuture Class". Qt Project. Archived from the original on 1 June 2013. Retrieved 26 June 2013.
  52. ^ "Seastar". Seastar project. Retrieved 22 August 2016.
  53. ^ "stlab is the ongoing work of what was Adobe's Software Technology Lab. The Adobe Source Libraries (ASL), Platform Libraries, and new stlab libraries are hosted on github". 31 January 2021.
  54. ^ 2013년 1월 12일 Wayback Machine에 Groovy GPars 아카이브 완료
  55. ^ Cujo.js
  56. ^ JavaScript when.js
  57. ^ 약속/A+ 사양
  58. ^ 약속들
  59. ^ JavaScript MochKit.비동기
  60. ^ JavaScript Angularjs
  61. ^ JavaScript 노드 약속
  62. ^ "JavaScript Q". Archived from the original on 31 December 2018. Retrieved 8 April 2013.
  63. ^ JavaScript RSVP.js
  64. ^ YUI JavaScript 클래스 라이브러리
  65. ^ YUI JavaScript 약속 클래스
  66. ^ 자바스크립트 블루버드
  67. ^ Java JDferred
  68. ^ 자바 파르세크
  69. ^ 목표-C MAFuture GitHub
  70. ^ 목표-C MAFuture mikeash.com
  71. ^ 목표 C RXPromise
  72. ^ ObjC-Collapsing Futures
  73. ^ Objective-C PromiseKit
  74. ^ 목표-C objc-promise
  75. ^ 목표-C OAPromise
  76. ^ OCaml 레이지
  77. ^ Perl 미래
  78. ^ Perl의 약속
  79. ^ Perl 리플렉스
  80. ^ Perl 약속:ES6
  81. ^ "Promise::XS - Fast promises in Perl - metacpan.org". metacpan.org. Retrieved 14 February 2021.
  82. ^ PHP 대응/약속
  83. ^ Python 내장 구현
  84. ^ 파이톤퓨처스
  85. ^ 트위스트 딜레이드
  86. ^ R 패키지 미래
  87. ^ 미래.
  88. ^ 루비 프로미스 보석
  89. ^ 루비리부
  90. ^ "Ruby Celluloid gem". Archived from the original on 8 May 2013. Retrieved 19 February 2022.
  91. ^ 루비 미래 자원
  92. ^ 선물 상자
  93. ^ Twitter의 유틸리티 라이브러리
  94. ^ "Swift Async". Archived from the original on 31 December 2018. Retrieved 23 June 2014.
  95. ^ Swift Future Kit
  96. ^ 스위프트 애플 GCD
  97. ^ Swift Future Lib
  98. ^ 시그너처/지연
  99. ^ Thomvis / Bright Futures
  100. ^ 벨로지에로프/스위프트코루틴
  101. ^ tcl-internal의
  102. ^ 비동기/대기에서는 실제 문제가 해결됩니까?
  103. ^ Go 언어 패턴 미래
  104. ^ 이동 언어 패턴

외부 링크