I once helped test one of the early true multiprocessor Unix kernels (more than one processor could be running kernel code at the same time). My contribution was a program called `churn` that was easily tweaked to hammer on particular system calls with many processors at the same time. It was great fun! Only one configuration failed to crash the system. (It was also a fun use of code coverage*.)
...
Brian Marick's Post
In Reply To: this post
Likes: 0
Boosts: 0
Hashtags:
Mentions:
Comments
Displaying 0 of 1 comments
Brian Marick
In response to this post...
In one configuration, what I "churned" was the mount/umount system calls (used to attach new disks to the system). I discovered a race where badly-timed sequences of mounts in a short time would crash the system.
Tempers were somewhat frayed by that time in the project, as I recall, and I got dressed down by what we'd today call the CTO for filing stupid bugs: no actual user would ever have that pattern of behavior.
...
...
Later, a crash bug was reported from the field. It turns out its fix also fixed my bug. (So, if my report had led to a fix rather than a dressing-down, a customer would have been spared that crash – we had many fewer customers than a typical OS today, so crashes mattered more.)
by Brian Marick ;
Likes: 0
Replies: 1
Boosts: 0