User loginNavigation |
Asynchronous messaging as integral part of programming languageI come from a world where asynchronous message passing is the normal way of designing your applications. The operating system, called OSE, is designed primarily for this. It took a large number of years before it got a mutex... Now that things are becoming more and more concurrent, this programming paradigm starts to become more and more attractive. The reason is that this will create concurrency on a much higher level, making communications between processes taking less bandwidth. My own finding is that if you construct a thread/process that has the following design: myProcess initialization code forever getMessage if message in wait queue continue executing message else start message execution if response needed, put message into wait queue end if end forever end myProcess The important thing here is that the process has only one synchronization point, the line saying "getMessage". After that, it will work on the message until it needs a response from someone in order to continue, or until the work is done and a reply has been sent. The problem is that above construction is non-trivial to implement in languages like C, and it is the wait queue that has the complexity. I would like support from a language to make this easier. If you also consider that you might want to make decision about what objects will be put in which core/process/thread late in the design, and maybe also being able to change this after the first version has been shipped, this becomes an interesting problem. I come from a real-time world where you want things to be quick and easy to design and implement from the beginning, and then possible to fine tune until the performance and characteristics are just the way you want it. My idea here was to concentrate on the popular object-oriented approach. The process above would then be a (special?) class, where the methods would actually be messages being sent to an instance of that class. This way, the programmer does not need to learn any new special stuff to get things done. The idea here would be that the methods describe sequences to be executed, where each method corresponds to an asynchronous message being received by the object. If the sequence calls another object that uses asynchronous message passing, the compiler handles the fact that the method will return to main loop, put its state into a wait queue, send the request and then wait for an answer. When the answer comes, it will continue in the method where it left off. One implication of this is that the accesses to the internal state of the object is subject to concurrency, so some way of specifying what needs to be atomic must be offered to the programmer to help the compiler. Or at least, I think so... Anyone has any thoughts on this? Am I on to something here, or just out in the blue dreaming? By Mats at 2011-08-24 11:59 | LtU Forum | previous forum topic | next forum topic | other blogs | 13772 reads
|
Browse archives
Active forum topics |
Recent comments
16 weeks 1 day ago
16 weeks 1 day ago
16 weeks 1 day ago
38 weeks 3 days ago
42 weeks 5 days ago
44 weeks 2 days ago
44 weeks 2 days ago
47 weeks 2 hours ago
51 weeks 4 days ago
51 weeks 4 days ago