Living life in parallel

I know it seems like I don't have a job, working from home and all (and updating this blog thing), but the truth is that I do. In fact, I've been working at the same (computer) company for almost 8 years now; who woulda thought?

In any case, the past week or so I've been brushing up on new parallel processing technologies (like Intel Threaded Building Blocks) in anticipation of my next work project. And today I received it: Mentor a team of engineers in China as they attempt to multi-thread Open-iSCSI. Basically, I'll be doing program management, and advising them technically, both on an overall architectural level and on an implementation level.

For those interested, iSCSI is basically a protocol that helps implement network storage over TCP/IP infrastructure. While I do need to study the details of the algorithm (and current implementation of it in the Open-iSCSI project), my background is in both networking, and, more importantly, in designing (and writing) parallel programs; lately, I've been doing a lot of teaching on the subject. In fact, most of my "professional life" had been in supporting (crazy-complicated) network processors, which are able to run up to 128 hardware-based threads at once. Making them all play nice together was a challenge. haha.

But that experience proved to be fortuitous; multi-threaded programming is all the rage now (for computer folks, that is). Still, there is much to learn, so I've been checking out a couple of cool - I use the term within the context of work - sources like the Thinking Parallel blog, the Blogs@Intel (specifically under "Research@Intel" and "Intel Software Network Blogs") and the TechRepublic blogs.

While you may not be interested in the actual details of writing multi-threaded software (some days I'm not either - ha!), you may find the analytical method - looking at a problem from this different perspective - curious, and, maybe, even provocative. In these situations, you now have many entities working towards a common goal, but since they are independent for the most part, you'll find unintended consequences galore, including, but not limited to, one stomping on another's set of resources, ruining the whole operation. Again, it's a difficult problem to get everyone to play nice sometimes - especially as the numbers involved go up and up and up.. even if all have the best intentions in mind. And this is a lesson that has application much beyond the computer world..