Ambition Rears its Ugly Head

*WARNING* This post is completely Computer Science related. */WARNING*

So, last December, I wrote a bit of a rant about concurrency as opposed to parallelization and the basic idea of merging Object Oriented and Concurrency Oriented designs. The idea seemed so completely beyond my scope of reasoning at the time, and I stopped letting myself think about it, but I realized a month or so ago that I need a senior project next year. I humored the idea briefly and quickly abandoned it, simply because, again, it seemed so huge. I decided this semester that I definitely want to go to grad school, possibly, likely pursuing my PhD, and to get into a top program - especially one where you're assured a Research Assistanceship - requires impressive work.

I'm looking at Human Computer Interaction work in a big way, but projects in that are just beyond the scope of what I have the time, resources, or background to do effectively; so every time I tried to think of a project, things came up blank. Then, the other day, I was zoning out in class, and I realized that I may be able to pull this concurrent object thing off; maybe not well, but as a proof of concept. It's a problem that engages me, should certainly going to look impressive, and will give me lots of new experience in areas I otherwise wouldn't be touching with a 10 foot pole in the normal curriculum.

That said, I really just need to talk about the idea, hash out the semantics, and jot down a few starting points as a way of clearing my head (it's about the only school related thing I've been able to think of for days) and to provide an easier way of explaining what I'm trying to do to my professors in the near future. So, bear with me, and hopefully this will be interesting.

First of all, I want to discuss the need. Everything is multi core now. Quad cores have hit the market, with 6 core processors coming down soon and 8 not far down the pipe. We need to write programs that will effectively use these resources. Most code these days is still written in a generally sequential fashion. Functions call other functions which then call more functions that they use to compute the value that they return to the function that called them, which then go on to call more functions until the final, desired result is met. Obviously, this is an incredibly simplified description, but people who are still reading should either understand how simple that is or be grateful for the abstraction. Now, the problem is that a lot of these interactions don't really depend on one another, so while useful computation could be being done on another processing element, your just waiting on the one your program is scheduled to, waiting for your Person Object to tell you its "name" is "Gary" instead of moving on and making sure that 19 isn't greater than 20.

How do we get around this?

Currently, there are a couple of chief methods. One technique utilized chiefly in High Performance Computing circles is parallelization - intentionally breaking up one problem into many smaller problems and actively telling different processing elements to handle different parts. The problem here is that it isn't a universally applicable technique. Certainly, lots of problems can be broken up into smaller ones, but this technique requires a completely different view of the system as we design algorithms. I mean, on a multi-core machine, we can make only slight modifications to a bubble-sort that make more computationally efficient than a standard quick or merge sort - sorting techniques that are much more difficult to properly parallelize. The other standard work around is simple threading; but anybody who has worked with threads knows the risks of critical areas, locks, and all of the other problems that the shared memory of a threaded environment can create.

There is at least one other language, however, that takes a different route: Erlang.

Erlang champions what its creators refer to as "concurrency oriented design". One of the most unique features of the language is that you can create "processes" - not heavy-weight system processes managed by the OS, but light weight Erlang processes managed by the Erlang RTE - which operate independently of one another and communicate through asynchronous message passing. Supposedly, these processes will essentially automatically propagate across a multi-core system, operating concurrently and giving practically n speedup on an n core system.

So, here's what I'm going to try to do:
Create an (easily subclassed) object library in C++ that will provide for similar behavior in Objects of its type.

Specifically, I want to create objects that persist and operate concurrently, requesting data from and reporting results to one another through asynchronous message passing and going about their business until requested data become necessary.

I have a few ideas for implementing a couple of features, but the following are issues that have me scared shitless:

Functional dependency -
how on earth do I determine when we need to pause and wait for a return value? Building a library to generate a dependency tree is a whole separate problem; generating one that doesn't kill performance with overhead (and that I can actively check to determine what I do have values back for) is worthy of its own senior project. If I want to make it possible to write code to work within this framework without needing to adopt new coding practices, I can't require additional calls to check each variable to see if it's in the process of being assigned before it's used...I have a couple of shaky ideas here, but they're related to the next problem

Message Passing -
I have a wonderfully simple (if ill advised) idea for queuing up function calls (overloaded . operator, here I come)...but how do I track the caller and return the value to it? Is there some way to make this return operation something that will interrupt whatever other action the calling Object was doing to make sure it gets values promptly?

Side Effects -
Side effects are dangerous in a concurrent world because they mean we can't be sure that a value is the same now as it was a millisecond ago. It may be worthwhile to try and make each function call virtually atomic to protect data integrity, but will this create too much overhead for simple, read-only methods that could be exempt from such scrutiny?

There are more, but I just had a brain fart, and I've gone on long enough already. I have enough reading to do on C++ (really, mostly standard C) to keep me busy all summer when I'm not at work. I need to familiarize myself with function pointers, with C's methods for manipulating memory (and hopefully access to it), and a lot more...but as daunted as I am, I'm still excited.

The other thing I hope to do with this project is to develop it in a strongly "literate programming" style, so when I'm done, I'll hopefully have a clear, legible document describing the code and why it has been developed in the way it has that I'll be able to publish on its own - and something worth publishing really is the goal here. So, you all may have that to look forward to a year or so from today.

Here's to shaping the future of the industry!

edit:
Just a note that I keep on realizing more and more issues with returning values and whatnot...I'm starting to fear that making this work in a seamlessly OO style may require compiler alterations...I guess this is why I'm only going to be looking at a proof of concept project to start.