Log in

No account? Create an account

More on threads... - Journal of Omnifarious

Sep. 23rd, 2007

03:40 pm - More on threads...

Previous Entry Share Next Entry

In the post entitled Threads, a neccessary evil or just a bad idea in search of a problem? I go off on a few related tangents and don't really tie it all together well. So I'm going to summarize in this post now that I've had a chance to think about it longer.

My basic idea is that most concurrency issues have the implicit assumption of locality. Basically it's less expensive to access data that's close to you. This means that in many environments having multiple threads of execution communication is resolved by explicit message passing because 'directly' modifying the data would be way too slow and it would all be implemented underneath with message passing anyway.

I do not think there is a magic threshold below which it becomes a good idea to abandon this strategy in favor of a model in which multiple entities work on a shared piece of data and keep this data from ending up in a jumbled and confused state by explicitly locking each other out of the portions they're working on.

I think that message passing is the appropriate model to use for all situations in which you have multiple threads of execution.

procyon112 was kind enough to point me at pi calculus, which is a formal mathematical model that extends lambda calculus with message passing to create a form of lambda calculus that embraces concurrency. On further research, it looks like most Process calculi are based on message passing, which makes sense. It's very hard to mathematically model a system in any other way.

Current Mood: [mood icon] contemplative
Current Music: Faith - Delerium