-
Notifications
You must be signed in to change notification settings - Fork 0
/
resource.slide
52 lines (29 loc) · 1.57 KB
/
resource.slide
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Resource Management
Go concurrency bootcamp #2
23 May 2013
Tags: concurrency, bootcamp
Author: Joel Eidsath
http://gammafn.com/cv
* There are limits to everything
Life, money, time, database connections.
.play resource/limit.go /START OMIT/,/END OMIT/
* What is GetConnection doing wrong?
.play resource/limit.go /START2 OMIT/,/END2 OMIT/
It always gives out a connection whenever asked. In a resource-limited world, this is bad.
* What if GetConnection blocked instead?
.play resource/limit2.go /START OMIT/,/END OMIT/
* Usage remains the same!
.play resource/limit2.go /START2 OMIT/,/END2 OMIT/
We've added some more database initialization, but GetConnection usage doesn't change. Nice!
* Here is the pattern (The Go Semaphore)
.code resource/pattern.go /START OMIT/,/END OMIT/
* Addendum: What's wrong with this?
.code resource/badpattern.go /START OMIT/,/END OMIT/
We can get rid of the initialization by reversing the direction of our semaphore channel usage. That's good, right?
* Maybe not
The three "happens before" guarantees in the [[http://golang.org/ref/mem][Go Memory Model]]:
- "A send on a channel happens before the corresponding receive from that channel completes."
- "The closing of a channel happens before a receive that returns a zero value because the channel is closed."
- "A receive from an unbuffered channel happens before the send on that channel completes."
We have no guarantee (as of Go 1.1) that a send to full channel does not complete before any further receives. The last example is not guaranteed to function as a proper semaphore.