Concurrency Contexts

I noticed my self saying “where the script is run”, describing what thread was executing the script code in my C++ app. Is it more natural to think of a thread as a physical context, comparing it to a ‘where’ instead of ‘what’? In the real world threads are represented by objects that do something, while no one actually thinks of something as having two different functions. The TV produces both light and sound, but this isn’t by coincidence. Someone created the aggregate function of producing both light and sound by coupling two different objects that do one thing. Just as none of the speaker and screen’s parts overlap (physically impossible), none of their code would overlap if they were made of software.

Applying the idea to threads, why does the code have to overlap between threads? Is sharing memory a prerequisite to concurrent execution, or is it simply an easy way out of your problem that could probably be better understood?
Hmmm. In my case sharing memory between threads makes it very easy to work with the audio data, but maybe using separate processes would be a better analogy? One way or another, it seems like having ONE perfectly-defined abstraction for concurrent execution would be the way to go.
By | 2008-11-22T23:10:00+00:00 November 22nd, 2008|Uncategorized|1 Comment

One Comment

  1. Michael Barber November 23, 2008 at 10:46 am - Reply

    What you’re describing sounds a lot like message passing concurrency or the actors model. This is how, e.g., Erlang works.

Leave A Comment

− 3 = 5