context: i was curious how much faster it would be to use atomics instead of locks to handle mutating the failures member.

(looks like it's about 45ns/op to use locks, 8ns/op to use atomics, if you were curious)

// Trip increments the failure count of the current Breaker.
func (b *Breaker) Trip() {
   atomic.AddInt64(&b.failures, 1)
}

// Reset resets the current Breaker's failure count to zero.
func (b *Breaker) Reset() {
    atomic.StoreInt64(&b.failures, 0)
}
```​

Acceptance Criteria:

• Add atomic operations to Trip() and Reset()
• Improve tests by adding benchmarks to operations (optional)

yo! i was poking around that breaker lib ... there's some raciness afoot (try running the tests on master with ​-race​ on, or write a benchmark that calls ​Trip()​ repeatedly)

• Investigate race issue
• Improve tests by adding -race
• Improve tests by calling Trip() repeatedly
• Improve tests by calling Trip() in a multi-goroutine context

on those channels where the value doesn't matter, you can send down an empty struct too (there's a Dave Cheney post about that somewhere, since it takes 0 bytes)

http://dave.cheney.net/2013/04/30/curious-channels

• Use empty structs to signal other goroutines when to trip the breaker.

Reset() is currently unreachable here: https://github.com/kellydunn/breaker/blob/master/breaker.go#L109-L110

The intent of Do is to get either a signal from the timeout channel or the err channel, or succeed with its call. We could also have a successchan that could poll on success of the event, which would be observing the absence of an error on the function that's being called.

Acceptance Critieria:

• Ensure Do() exits
• Improve coverage by adding a sufficient test.