From 64d2a7c8945ba05af859901f5e248f1befdd8621 Mon Sep 17 00:00:00 2001 From: Michael Stapelberg Date: Tue, 3 Dec 2013 09:43:15 +0100 Subject: Imported Upstream version 1.2 --- doc/articles/concurrency_patterns.html | 79 ---------------------------------- 1 file changed, 79 deletions(-) delete mode 100644 doc/articles/concurrency_patterns.html (limited to 'doc/articles/concurrency_patterns.html') diff --git a/doc/articles/concurrency_patterns.html b/doc/articles/concurrency_patterns.html deleted file mode 100644 index 62168b840..000000000 --- a/doc/articles/concurrency_patterns.html +++ /dev/null @@ -1,79 +0,0 @@ - - -

-Concurrent programming has its own idioms. A good example is timeouts. Although -Go's channels do not support them directly, they are easy to implement. Say we -want to receive from the channel ch, but want to wait at most one -second for the value to arrive. We would start by creating a signalling channel -and launching a goroutine that sleeps before sending on the channel: -

- -{{code "/doc/progs/timeout1.go" `/timeout :=/` `/STOP/`}} - -

-We can then use a select statement to receive from either -ch or timeout. If nothing arrives on ch -after one second, the timeout case is selected and the attempt to read from -ch is abandoned. -

- -{{code "/doc/progs/timeout1.go" `/select {/` `/STOP/`}} - -

-The timeout channel is buffered with space for 1 value, allowing -the timeout goroutine to send to the channel and then exit. The goroutine -doesn't know (or care) whether the value is received. This means the goroutine -won't hang around forever if the ch receive happens before the -timeout is reached. The timeout channel will eventually be -deallocated by the garbage collector. -

- -

-(In this example we used time.Sleep to demonstrate the mechanics -of goroutines and channels. In real programs you should use -time.After, a function that returns -a channel and sends on that channel after the specified duration.) -

- -

-Let's look at another variation of this pattern. In this example we have a -program that reads from multiple replicated databases simultaneously. The -program needs only one of the answers, and it should accept the answer that -arrives first. -

- -

-The function Query takes a slice of database connections and a -query string. It queries each of the databases in parallel and -returns the first response it receives: -

- -{{code "/doc/progs/timeout2.go" `/func Query/` `/STOP/`}} - -

-In this example, the closure does a non-blocking send, which it achieves by -using the send operation in select statement with a -default case. If the send cannot go through immediately the -default case will be selected. Making the send non-blocking guarantees that -none of the goroutines launched in the loop will hang around. However, if the -result arrives before the main function has made it to the receive, the send -could fail since no one is ready. -

- -

-This problem is a textbook example of what is known as a -race condition, but -the fix is trivial. We just make sure to buffer the channel ch (by -adding the buffer length as the second argument to make), -guaranteeing that the first send has a place to put the value. This ensures the -send will always succeed, and the first value to arrive will be retrieved -regardless of the order of execution. -

- -

-These two examples demonstrate the simplicity with which Go can express complex -interactions between goroutines. -

-- cgit v1.2.3