The other day i was trying to solve a wonderful advent of code puzzle while at
the same time trying to learn more about programming in Plan9. The puzzle in
question was 2022, day5. where supposedly you control a giant crane adding and
removing boxes from different piles. You start with an initial configuration of
boxes in different piles and then you can pick up one and place it on another.
In the end you want the state of each stack. There are probably billions of
more efficient approaches to this problem but it originally got me thinking on
how i could use the function call stack. The observation of having to maintain
state in different stacks somehow got me thinking about threads, and i decided
to take a look at the wonderful libthread of plan9. From the
manual page thread(2)
we see that the programming model involves both channels (event-based) and
shared memory mechanisms. It also is quick to point out the ability to spawn
processes (procs) that can contain threads, or just threads within a proc. We
also learn that threads contained within a proc share memory so it is valid to
pass pointers from one to the other. Having written a fair share of golang i
was directly intrigued from the Alt/alt() construct. This is in essence a
select on multiple channels. It can accept various channels for the thread to
send or receive data, and if some actions are readily doable it will pick a
random one and do it. Otherwise it will block until one of the actions in the Alt
struct are doable. Constructs to golang exist to notify downstream processing
threads of exiting by closing th they listen on. If you close all the channels
that a thread is doing an alt() on, it return -1 and exit.
In terms of resources to learn more about libthread, the manual page is pointing
us to
/sys/src/libthread/example.c
a sample program that will read mouse click events and clock events. One other
thing to notice here is that this program is firing up more processes, to
actually read the mouse events. This is because blocking system calls like
read() will block the whole proc (and all the threads that are executing inside
it). Therefore it seems that when dealing with I/O (or generally blocking
calls) we should do so in different dedicated procs and let the operating system
deal with their scheduling. Another sample program exists in the same
directory, which is a very elegant concurrent prime number sieve
/sys/src/libthread/tprimes.c
Finally there is also a fantastic talk by rsc at
his homepage
which really goes into great detail of the implementation of libthread and the
design choices.
Since i have found the pattern of one worker thread needing to communicate with
multiple workers over pairs (or triplets if we want to have control messages) of
channels quite a common one in golang, i wrote
this demo program.
The main thread will spawn N (5 in this case) threads and write one char at
each. It will then read from those threads in reverse. The worker threads are
utilizing the alt construct while the main thread explicitly send() and recv().
Looking at libthread really made me appreciate both Plan9 and its libthread as
well as golang more. The design choices and the amount of polishing, to make
golang IPC usable by people just want powerful concurrent primitives, have their
roots in libthread. On the other hand when writing golang, when questions
involving task affinity, cache locality etc of the data being exchanged over
channels arise, the answers are usually quite complex and sometimes we discover
that the runtime won't allow certain operations (and for good reasons). However
seeing how libthread on Plan9 was intended to work, straight from the manual
page we get powerful primitives to deal with concurrency both in thread and in
process, as well as clarity and control on how the operating system scheduler is
going to interact with us.
- - - - - - - - -