Many programming languages allow defining global data with simple declarations like:

    int x = 3;

This global data is, well, global and is accessible to any thread started up by that program. This is called implicit sharing. But since there is no inherent synchronization to accessing it, all kinds of inadvertent threading problems can arise from using it.

One way to resolve this is for each thread

C is arguably the world's most successful programming language. Its success has, of course, endlessly tempted people to improve upon it. Thus, C is probably the patriarch of the longest list of languages. Notable among these are C++, the D programming language, and most recently, Go. There are endless discussion threads on how to fix C, going back to the 80's.

So this is well trod ground. What

Back in the bad old DOS days, to have a large, capable application meant writing it in assembler because:

1. hand written assembler was often more than twice as fast as C
2. with very tight memory, the smaller the app the more room there was for data
3. compilers in the early days were rather poor

Early successful apps like Lotus 1-2-3 (and of course, DOS itself) were written in assembler.

But, as

In the last blog, I discussed one of the basic principles of writing safe systems is having a backup that is decoupled from the primary. For example, hospitals normally have a backup power generator in case the grid power fails. These generators are normally located in the basement. In New Orleans, the same event (hurricane Katrina) that took out the grid power also flooded the basements and took

A recent article in Wired [1] piqued my interest because it touched on an interesting subject. In it, a medical "gamma knife" used to treat cancer patients had
suffered from a software glitch. The emergency shutoff switch had no effect, causing the staff to have to run in and extract the patient before he was killed.

How does one create a safe machine? The first thought one has is to make the

In the last installment, we saw how nested functions are implemented. If you're thinking ahead, you'll ask "but what about pointers to nested functions? Does that work?" The problem is that the nested function, in order to work, requires and extra hidden parameter - the static link to its statically enclosing function's stack frame. This extra parameter means an ordinary function pointer won't

We're all familiar with C functions and how they can call each other recursively:

int foo(int i)
{
    int a;
    a = bar(i);
    return a + 1;
}

int bar(int i)
{
    if (i & 1) return foo(i);
    return i;
}

When a function is entered, a stack frame is created that holds all the local function variables and parameters, and a back pointer to the caller's stack frame. In x86 assembler, the stack frame setup

In the last installment, we talked about how changing a declaration in one module can unexpectedly change the behavior of another module, and how language features can mitigate that. Here are some more features of the D programming language designed for that purpose.

Final Switch

Given an enum declaration:

 enum E { A, B, C }

and in the remote module there's a switch statement:

 E e;
 ...
 switch (e)
 {