This is a post in the
metronome-cacophony series.
Other posts in this series:
- May 01, 2018 - Introduction
- May 01, 2018 - Basic synchronous solution
- May 01, 2018 - Ticker
- May 01, 2018 - Goroutine
- May 01, 2018 - WaitGroup
- May 01, 2018 - Sharing state
- May 01, 2018 - Atomicity
- May 01, 2018 - Mutex
- May 01, 2018 - Channels introduction
- May 01, 2018 - Channel select
- May 01, 2018 - Goroutines and channels
- May 01, 2018 - Solution with channel
- May 01, 2018 - Videos and final word
- May 01, 2018 - Appendices
Metronome's Cacophony (14/14) - concurrency in Go - Appendices
Appendices
A. Concept of volumeMeter
All scenarios are using a mysterious variable volumeMeter
. It allows me to emulate lag of volume measurement in controlled fashion
Note:
You don't need to study the contents of volumeMeter
as long as you assume that it is a function that provides current volume and is designed to simulate short- and long-running tasks in controlled manner.
For all of the examples in this series volumeMeter
is a provider function created with:
1func New(
2 baselineDuration time.Duration,
3 delaySimulator generator.Duration,
4 tracker track.Tracker) metronome.VolumeMeter {
5
6 return func() (volume int) { // contract of metronome.VolumeMeter
7
8 //use delay simulator to generate a delay corresponding to some baseline
9 // baseline is needed so that the delay is not 1s for an application working at 1ns resolution
10 simulatedDelay := delaySimulator(baselineDuration)
11
12 //pretend the execution of "volume measuring" takes more time than it should
13 time.Sleep(simulatedDelay)
14
15 // Obviously the volume is random (well, pseudo-random) just for the purpose of the demo.
16 // In real-life, if the volume was to change so instantly between extremities there
17 // would be little point trying to measure it to produce beats. volume = rand.Intn(101)
18
19 event := track.Event{
20 Category: "volume",
21 Content: strconv.Itoa(volume),
22 Duration: simulatedDelay,
23 }
24
25 tracker(event)
26
27 return
28 }
29}
baselineDuration
- equal/close to beat interval, because the simulated delays cannot be too far off the desired beat intervals, interval of 100ms with simulated delay of 5s would just make it silly,delaySimulator
- function describes the characteristics of delay- optimistic/short - e.g. 0.5 *
baselineDuration
- oscillating (triangular wave) - smoothly changing between [0.2, 2.5] *
baselineDuration
- random - capped between [0.2, 2.5] *
baselineDuration
- optimistic/short - e.g. 0.5 *
In the examples volumeMeter
is not passed in via function arguments but by closure.
Code on GitHub.
B. Diagram convention
An example diagram:
The rest of diagrams will follow similar convention.
The first row illustrates expected frequency of metronome's beats. It is theoretical, based purely on bpm
and
numberOfBeats
parameters, so is not a result of real code's performance metric.
Note: Row with simulated beats does not pretend to know how long the first measurement will take. The first (simulated) beat will happen immediately after application starts.
The second row reflects the actual time (real code performance) during which volume measurement was taking place. The number is the amplitude of measured volume.
The third row shows actual (real code performance) beats, each of them corresponding to a single beat. The letters "I" and "O" in first and third row represent tIcks and tOcks (or binary indicator) so that it is easier to spot ordering anomalies (actual beats tooltips also help with that).
You can click through any diagrams (apart from the above example) to open an interactive version of it.
That will allow you to zoom and pan chart items.
It also will allow you to inspect the beat's tooltip information (to read value of volume
or beatCount
),
and understand which volume measurement fed into which beat performance.
Note: Once the interactive version opens, don't forget to click on the diagram again (set focus) to interact with it.
C. More materials for you to plough through
Google I/O 2013 - Advanced Go Concurrency Patterns
Go Concurrency Patterns (2012)
Concurrency is not parallelism
Go Tour (learn Go in your browser)
Concurrency made easy - GopherCon SG 2017
GopherCon 2017: Kavya Joshi - Understanding Channels
This is a post in the
metronome-cacophony series.
Other posts in this series:
- May 01, 2018 - Introduction
- May 01, 2018 - Basic synchronous solution
- May 01, 2018 - Ticker
- May 01, 2018 - Goroutine
- May 01, 2018 - WaitGroup
- May 01, 2018 - Sharing state
- May 01, 2018 - Atomicity
- May 01, 2018 - Mutex
- May 01, 2018 - Channels introduction
- May 01, 2018 - Channel select
- May 01, 2018 - Goroutines and channels
- May 01, 2018 - Solution with channel
- May 01, 2018 - Videos and final word
- May 01, 2018 - Appendices