Then I had another thought: Physics disgusts me a little bit now, but I used to enjoy doing physics. Why did I enjoy it? I used to play with it. I used to do whatever I felt like doing - it didn't have to do with whether it was important for the development of nuclear physics, but whether it was interesting and amusing for me to play with. When I was in high school, I'd see water running out of a faucet growing narrower, and wonder if I could figure out what determines that curve. I found it was rather easy to do. I didn't have to do it; it wasn't important for the future of science; somebody else had already done it. That didn't make any difference. I'd invent things and play with things for my own entertainment.

This strategy worked wonders for me. It allowed me to retain relative sanity, and I have always had an absolute blast doing it. It has also led me to unique places and opened up great opportunities as a byproduct.

This post is about one of these things that I played with for no good reason other than pure fun. At one point, I decided that I would like to know how threading works and that the best way to do it was to write a threading library entirely from scratch. I mean the stuff that hides behind all those pthread_* calls that you know and love from C. Amazingly, I was able to chew through all this bit by bit and build something reasonably simple that still did all those things that mystified me in the past.

The posts linked below describe a more or less complete threading library written in simple C and based on Linux syscalls. The library (almost) does not use glibc, but it takes some inspiration from it. I start from the basics like calling syscalls from C, heap management, printing text, etc. Then, I move to thread creation, cancelation, joining, and scheduling on top of that. It all ends with synchronization primitives: a mutex implementation with priority inheritance, as well as condition variables and RW locks.

Here's the code and a nice clickable cross-reference if you want to cut right to the chase.

Table of Contents

1. Syscalls, memory, and your first therad

2. The pointer to self and thread-local storage

3. Futexes, mutexes, and memory sychronization

4. Joining threads and dynamic initialization

5. Cancellation

6. Scheduling and task priority

7. RW Locks

8. Condition variables

9. Final thoughts

For example, when doing the function grapher exercise, I was disappointed that I could not pass the function being plotted to the module doing the work. Instead, I had to generate an array of 3D points in a particular order so that the grapher could build the desired polyhedron out of them. It is cumbersome, and it could, in principle, be automated. It also makes the grapher module leak abstraction. You need to be aware of its internal workings to plot what you want.

The issue of leaking abstractions became more visible when I started using OpenSCAD to model the enclosure for my NAS project.

Firstly, I wanted part of the enclosure holding the disks to be parametrized by the number of disks it could contain and their size. I also wanted the part of the enclosure holding the optical drive and the ARM board to be parametrized by the size of these components. Everything worked fine until I had to figure out how to connect these parts. I could not determine the locations of bolts and screws without knowing the internals of each of the modules, and there was no obvious way for the modules to expose the necessary information to the outside world. I ended up defining a bunch of helper functions that would compute this information when supplied with the same parameters as the modules they described. It quickly became cumbersome, though, and started to look pretty ugly.

Secondly, I needed to design the components separately to 3D print them later. But I also wanted to visualize the model as a whole to see if things fit together. That ended up being impossible without knowing the dimensions of the parametrized components, the arrangement of attachments (which were a non-trivial function of the module's input parameters), and the frame of reference in which each part was designed.

The last two issues fundamentally stem from the fact that, in OpenSCAD, the abstract syntax tree of the program you're writing represents the geometry tree of the model you are designing. Significant improvements can be made if you divorce the two. For example, doing so would allow the module objects to have properties that you could use for integration without exposing how these properties were calculated internally. It would also allow for writing programs that analyze or manipulate the geometry tree in interesting ways before it is rendered. Solving the first issue is just a matter of making functions first-class citizens, which would probably be an easy change to the OpenSCAD language.

I finally managed to find enough time to make good on the threats I had made when I designed the chassis for my NAS and played with solving the issues mentioned above. I decided to use Go because it's a garbage-collected language with great tooling, and it compiles really fast. I designed a Java3D-like API that can be used to build the geometry tree of a model, which can then be compiled to OpenSCAD source and further processed by vanilla OpenSCAD. I used this system to design something of a non-trivial size that I needed - a small computer rack for all the electronic gadgets that accumulated under my TV table and evolved into a maze of wires, routers, and bare PCB boards.

I called the system GhostSCAD, and the TV table rack project is here. This article summarizes the results of this investigation.

Read more.

Subscribe now