Untangling code with flow-based programming
That’s why we live in this world where we follow this one particular [von Neumann] architecture and all the alternatives were squashed… Turing gave us this very powerful one-dimensional model, von Neumann made it into this two-dimensional address matrix, and why are we still stuck in that world? We’re fully capable of moving on to the next generation… that becomes fully three-dimensional. Why stay in this von Neumann matrix?
Dyson suggested a more biologically based template-based approach, but I wasn’t sure at the time that we were as far from three dimensions as Dyson thought. Distributed computing with separate memory spaces already can offer an additional dimension, though most of us are not normally great at using it. (I suspect Dyson would disagree with my interpretation.)
Companies that specialize in scaling horizontally—Google, Facebook, and many others—already seem to have multiple dimensions running more or less smoothly. While we tend to think of that work as only applying to specialized cases involving many thousands of simultaneous users, that extra dimension can help make computing more efficient at practically any scale above a single processor core.
Unfortunately, we’ve trained ourselves very well to the von Neumann model—a flow of instructions through a processor working on a shared address space. There are many variations in pipelines, protections for memory, and so on, but we’ve centered our programming models on creating processes that communicate with each other. The program is the center of our computing universe because it must handle all of these manipulations directly.
Velocity 2013 Speaker Series
You wake up one morning to discover your team has gotten a dreaded alert: your web application is performing badly. You dig through your code, but don’t see anything that stands out, until you open up Chrome’s memory performance tools, and see this:
One of your co-workers chuckles, because they realize that you’ve got a memory-related performance problem.
Don't be afraid of the bus
After a short period of time, beginners working with the Arduino development boards often find themselves wanting to work with a greater range of input or sensor devices—such as real-time clocks, temperature sensors, or digital potentiometers.
However each of these can often require connection by one of the two digital data buses, known as SPI and I2C. After searching around the Internet, inexperienced users may become confused about the bus type and how to send and receive data with them, then give up.
This is a shame as such interfaces are quite simple to use and can be easily understood with the right explanation. For example let’s consider the I2C bus. It’s a simple serial data link that allows a master device (such as the Arduino) to communicate with one or more slave devices (such as port expanders, temperature sensors, EEPROMs, real-time clocks, and more).
Handle sensitive data, free memory, and more
It may seem that when dynamic memory has been deallocated, we are done with it. We have avoided a memory leak and can confidently move on to other issues. In some cases this may be the case. However, we may need to be concerned with issues such as how we handle sensitive data and whether we need to even worry about freeing memory if the application is about to terminate. In this discussion we will examine these issues and others.
The Heap and System Memory
The heap typically uses operating system functions to manage its memory. The heap’s size may be fixed when the program is created, or it may be allowed to grow. However, the heap manager does not necessarily return memory to the operating system when the
free function is called. The deallocated memory is simply made available for subsequent use by the application. Thus, when a program allocates and then frees up memory, the deallocation of memory is not normally reflected in the application’s memory usage as seen from the operating system perspective.
Memory is typically deallocated using the free function. One concern deals with what happens when we try to free the same memory twice. Freeing a block of memory twice is referred to as double free. The following illustrates how this can be done:
char *name = (char*)malloc(...); ... free(name); // First free ... free(name); // Double free
More subtle occurrences of double free occur when pointers are aliased:
char *name = (char*)malloc(...); char *tmp = name; ... free(name); // First free ... free(tmp); // Double free
In an earlier version of the zlib compression library, it was possible for a double-free operation to result in a denial of service attack or possibly to insert code into the program. However, this is extremely unlikely and the vulnerability has been addressed in newer releases of the library. More information about this vulnerability can be found at cert.org.
A simple technique to avoid this type of vulnerability is to always assign NULL to a pointer after it has been freed. Subsequent attempts to free a null pointer will be ignored by most heap managers.
char *name = (char*)malloc(...); ... free(name); name = NULL;