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
53
|
# Winter 2025 Course Journal: EECS 491
Course Title: Distributed Systems
## Motivation
This is one of the only three upper-level courses that doesn't conflict
with my schedule. Also, Brian Noble is one of my favorite professors.
When he was teaching 482, Brian brings up 491 sometimes, and if he teaches
it, it has to be good. Although I'm not a software person, it might come
useful in designing a mesh of embedded systems.
## Go language
I wrote a little bit of Go in high school but it was nothing serious.
Brian said we use Go because it was invented at Google to power their
distributed systems, concurrency and all that stuff. He also emphasized we
were to write "idiomatic Go", which means making use of strengths in the
language.
Being C-like makes it easy to pick up, but there's new stuff. So far, my
favorite thing is the `for ... select` loop and it's incredibly cool.
Over the winter I've been doing an embedded project in C++ with FreeRTOS.
In FreeRTOS, one way to block a task until data shows up is to receive
from a queue. The problem is, I need to wait for three events (represented
as three structs), but you can only shove one type in a queue. So what
I ended up doing is write a wrapper struct with an event type and
a pointer, which I then cast to various types based on event type.
With Go, each queue would be a channel, and you could wait for three all
at once.
The `go` keyword in go spawns a goroutine, which is basically like
spawning a thread, but safer and cheaper.
Another big thing that's different from the C world, namely 482, is that
we're forbidden from using mutexes or any low-level synchronization
mechanism. We're also cautioned against passing values by pointer to two
concurrent processes. Copying a couple kilobytes is negligible compared to
network roundtrips.
## Non-deterministic behavior
I've taken 482, so I'm familiar with programs where things happen in
a different order each time. And I know that, if there is more than one
thing in a pool, you cannot predict which one is getting out first. This
can lead to non-deterministic behavior, and that's ok as long as it's in
the set of "allowed" non-deterministic behaviors. This reminds me of a Tom
Scott video that explains why computers "can't count", e.g. why the number
of upvotes on a Reddit post changes every time you refresh.
|
