Partager via

Getting started

  • Article

I have no idea how many concurrency-related blogs there may be on MSDN nowadays, but here's another one. Hopefully, there will be an angle or two that are unique or at least not common to all of them.

My name is Niklas Gustafsson and I work in the developer division as a software architect. The group I'm in is working on the problem of how we can make programming the inevitably concurrent hardware of the future a bit more approachable without forcing every developer in the world to start over and learn everything from scratch, an approach that sometimes seems to be the only way to deal with it.

I've only worked at Microsoft five years, but I've spent 20 years in development tools, mostly compilers and language-support runtimes. What I find interesting is that 20 years ago, when I was working on an Ada system (and was fresh out of college), programming concurrent applications seemed easier than with many of the tools available today. That language, which was made irrelevant by a series of fortunate events (such as the cold war ending and the rise of the personal computer), wasn't all about concurrency, but it had support for task parallelism and it was a lot easier to get things right than with today's threads + locks model.

The rendezvous concept was definitely limited, but it did force programmers to apply some degree of formalism to the interaction of tasks, something that is missing in the more informal threads model.

You won't hear me argue that we should resurrect Ada (which still lives on, by the way) as the solution, but it's interesting to ponder whether yesterday's technology was perhaps better suited for tomorrow's problems than what we have today is.

I'll just leave it there for this first entry of mine.

Niklas

Comments