The original vision

So, in an effort to sort out how this project is going to be reshaped, my advisor and I have decided that a good first step would be to firmly state the original vision and intentions.

Fundamentally, my first aim wasn't to improve performance so much as to bolster a modern, object-oriented programming language with a means of simple, nearly automatic, concurrent behavior by making method calls on an object natively asynchronous. Specifically, I wanted to implement this sort of behavior for shared memory systems using threads.

I feel that, in the ideal state, all calls of member functions from outside a given object should have the option of being called asynchronously (while all calls from within the object should be completed synchronously and immediately). We would need something presiding over memory in cases where a return value is expected, making sure that the location being assigned isn't read from until the return is completed.

I originally thought of using C++ because I made a few erroneous assumptions based on limited knowledge. I thought that I should be able to create a new class (let's call it AsynchronousObject) in which the . operator would be overloaded. Since one possible implementation of the . operator obviously receives a function pointer, it was my intent to overload the . operator in such a way that, when called with a function pointer, that function pointer would be loaded into a queue. Meanwhile, this class would, when instantiated, create a thread running a method that would check this function pointer queue and execute the functions in it in order, going to sleep when the queue was empty (only to be woken again when the . operator was next invoked on the object).

I had no real plans as to how to perform the memory monitoring or asynchronous returns, but given that I have worked with message passing frameworks for distributed memory systems that allowed for asynchronous behavior, I assumed that there must be some way to do this. One of my other reasons for working with C++ was that I felt that it's very detailed view of system memory would make this more feasible than with most other O-O languages (which, in my experience, tend to avoid providing much view of the actual machine).

As stated in the previous post, I ran into serious problems with this plan. For one thing, C++ does not allow the . operator to be overloaded. This wouldn't be the end of the world. It would still be possible for me to create a function that receives a function pointer and executes that particular operation asynchronously (which might actually even be the better choice) were it not for the other complication I ran into. Function pointers are pickier than I expected them to be. When creating a function pointer, you need to know its return type and the number and types of arguments it takes. While I may be mistaken on this point, too, this leads me towards the belief that it is not possible to create a single data structure to contain function pointers generically.

So, it would seem that I'm out of luck with C++, and I'm not entirely sure where to go. I'll post again later describing some of the options that have been mentioned.