Subject: survey on concurrent object-oriented languages Resent-Date: Thu, 02 Mar 2000 11:41:05 -0500 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Mon, 14 Feb 2000 08:35:56 -0800 From: Michael Philippsen To: gcf@npac.syr.edu CC: phlipp@ira.uka.de Hi Geoffrey, quite a while ago I've mentioned my survey of concurrent object-oriented languages to you and asked whether you would consider a survey for publication in CPE. Well, finally, here it comes. This survey is the most comprehensive survey on the issue I know of. 111 languages are categorized - about an order of magnitude more detail than in any other survey. About 50% of the pages are on the problems, categories, and proposed mechanisms. This first half of the survey covers three aspects: initiation of concurrency, coordination of concurrency and locality issues. As far as I know, there are no other surveys that discuss initiation and locality issues at all. The second half is devoted to a visual catalog of the languages and to references. The second half alone is a rich source of information that cannot be found elsewhere. I submitted the survey to ACM Computing Surveys three years ago and was astonished (and disappointed) to learn that they rejected it ("please re-submit"). I got two contradictory reviews, the decision must have been based on the second one. The first review sounded very good: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > I have read the paper, and I strongly recommend it for publication > in ACM computing surveys. I think it provides an excellent overview of > the issues involved in integrating concurrency within an > object-oriented languages, and of the various solutions that have been > proposed. It also contains the most complete surveys of existing COOLs > that I have seen. The only part that I think could use a little > improvement is the conclusion. After 43 pages of discussion about COOL > problems he has a very short conclusion which basically expresses the > hope that the survey will be useful. After spending so much time > reviewing the problems and existing solutions one would think that he > has some ideas about how to improve the situation, but if he does he > doesn't say so. He could at least describe the pros and cons of the > existing COOL categories for various application domains. His basic > conclusion is that no existing COOL solves all the outstanding > problems. > > The paper is well written and is easy to read. The only detailed > suggestion I would make is to change the name of section 3 from > "initiate concurrency" which reads like a command, to "initiating > concurrency" which reads more like a topic. Also he uses the term > "mixed-in class" which I have not come across before. I think he means > "mix-in class" which is a well known term. Apart from that I have no > problem with any of the terms or claims in the paper. In fact, I found > it enlightening. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In the current version that I'm submitting to CPE, I fixed all the minor bugs and have now a better conclusion, that points out what needs to be done in this area in future. The second review was unfair and even worse, killed all hope that a re-submitted version would be accepted. First, I have the impression that the reviewer has read the text only superficially. Some of the points that are criticized were simply not true. Second, the reviewer discusses only the section on concurrency coordination and completely ignores two thirds of the text. Third, another group of people were writing a survey on the topic of that section (and had not yet submitted their draft). From the inside knowledge and from the type of criticism the reviewer must be close to the competing group. (In the meantime, the other survey has been published in ACM Computing Surveys - and they did not even cite my techreport with a preliminary version of my survey although I *know* they have read it since the third author told me.) Because of the fact that I expect the second reviewer to kill any re-submission, I've asked other journals. But always, they refused to accept a survey because of its length. So I finally have put it away. But when you've signaled interest in the survey, I continued to work on it. I've updated the material to reflect the progress of the past three years. And of course, I worked on the relevant comments of the second review: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Comments for the author: > > A thorough survey of Concurrent Object-Oriented Languages is long > overdue, and this is a good start. This draft, however, could do with > a great deal of improvement, and should be extensively revised before > it is ready for publication. I've revised it and I hope that it is now in a better shape. > As a general comment, I find the proposed classification scheme rather > hard to digest, and I do not appreciate the funny symbols and stars and > sliders. It is not a bad idea to assign graphical symbols to identify > how languages are classified, but I really do not find that the chosen > scheme works very well. Well, I think that it is a matter of taste whether graphical notation is used or not. The appendix has a pictograph for each language discussed. The pictographs have several graphical components that are introduced and explained in the text. Someone who has read the text will easily see what features a language has. Someone who has only browsed through the text will easily find the paragraphs that talk about the notation. Moreover, it is easy to compare languages visually and to find languages with similar sets of features. In past couple of years I had quite a number of proof readers and helpers that *liked* the notation and found it useful. Anyway, I tried to better integrate the visual comparison and the introduction of the pictographs into the text. That might help to better understand the semantics of the pictographs. > In the introductory section, I find that an overview of the approaches > and the problems is missing. This makes it hard to see where you are > going until we get there. In particular, I would have greatly > appreciated a set of canonical problems in the introduction, so we > can see how languages or language features compare with respect to > their ability to address certain problems. Other authors you mention > (such as Papathomas) have taken such an approach, and it can work well. I worked on that. Chapter 2 now more explicitly identifies the relevant problem areas that must be dealt with when designing concurrent object-oriented languages. Some previous surveys are driven by some example problems. They walk the reader through the examples and how they could be handled with several language mechanisms. It is my impression that it is time to look at the general problems instead of working on examples alone. > Many of the problems are lurking in the current text (i.e., > readers/writers, synchronization constraints, initiating multiple > parallel activities, ...), but they are not organized in any way. This is simply unfair. The main issue of the survey is to organize the stuff. > I find your classification scheme unhelpful. Others don't. > For the life of me I > could not figure out what you meant by "object-centred concurrency" > (OCC) vs. "callee-oriented coordination" (COC). The callee *is* the > object, so what is the distinction? If "concurrency is confined within > objects" then clearly "concurrency coordination must be implemented at > the side of the callee". In OCC I assume you mean that objects may be > internally concurrent. If so, then I see no difference with COC. If > not, your text is unclear (which it is in any case). Furthermore, p. > 22, you state that no COOL supports OCC, so what use is the > classification scheme? Please use a classification scheme that helps > to distinguish languages, and then use clear exmaples that make the > distinctions clear. Some misunderstandings here. I've cleared up the paragraphs and renamed some of the categories. (Of course, there has never been an empty category.) > A classification scheme that makes it easier to compare language > features or approaches to canonical problems would be more staisfying > in the long run. It is easy to compare language features. The appendix with the pictographs is very helpful to compare language features visually. As I said above, I don't think that it is wise to do all the discussions based on examples. And the survey has a running example that demonstrates the different language mechanisms. > Your discussion of the inheritance anomaly is very obscure. Please > refer to Kafura and Lee's excellent article. > > [Dennis G. Kafura and Keung Hae Lee, "Inheritance in Actor > Based Concurrent Object-Oriented Languages," Proceedings > ECOOP'89, S. Cook (Ed.), Cambridge University Press, > Nottingham, July 10-14, 1989, pp. 131-145.] I must admit that I did not cite this particular article. Instead I've mentioned a more current one by these authors :-) > Please speak of "inheritance anomalies" as a number of specific, and > distinguishable effects, rather than generically of "inheritance > anomaly" (as if it were a disease, like cancer). Matsuoka describes > these different effects in detail. If you wish to make a point of > it, please summarize the different effects. Alternatively, please > use Kafura and Lee's description, which is very concise. > > In general, the discussion of inheritance anomalies in the survey > does not go anywhere. It is discussed very briefly, without any > convincing examples, and does not lead to any real insight into > the different language approaches. It is not the purpose of this survey to contain a sub-survey on inheritance anomalies. (Matsuoka and Yonezawa have devoted 43 excellent pages to this.) In my survey, the discussion of inheritance anomalies is intentionally brief (and without examples that show various forms of inheritance anomalies). The section tries to take the essence of previous work on inheritance anomalies and boil them down some design goals (isolate, seperate, history proceed-criteria, state proceed-criteria). This is quite coarse grained but it helps a lot in understanding when and why to expect inheritance anomalies. When working on the current version, I took care to clear up the section on inheritance anomalies to avoid further misunderstandings. Anyway, I might add another appendix on inheritance anomaly if this seems useful. > I have to say that I really hate the print server example. It is not > used consistently throughout the article, so only seems to serve in > random situations to make some arbitrary observations. Instead, I > would much prefer a set of canonical examples that illustrate classical > problems (challenges). > > I would also prefer to see some real code in a real language, not > made-up examples that do not really run. The PRINT_SERVER is annoying > because it does not look like it would work. I would expect that the > body of print_text should be treated as a critical section since shared > variables are accessed and updated, but this is not evident from the > code. Furthermore, clients will block if they attempt to disable a > PRINT_SERVER that is already disabled -- clearly not acceptable in a > real implementation. It is bad enough to have to use semaphores when > higher level constructs are not available -- please do not shove them > down the throats of the poor readers in your examples! The print-server example has been replaced by a bounded buffer. This new examples is as simple and short as the print server but it is more realistic and does not suffer from any of the print server problems mentioned by the reviewer. > Some more specific quibbles: > - p. 3, you should also reference Briot and Guerraoui, who have written > another survey of COOLs (to appear): "A Classification of Various > Approaches for Object-Based Parallel and Distributed Programming" > Please contact the authors, or see: > http://marylin.is.s.u-tokyo.ac.jp/~briot/papers/README.html I did not know that URL....But I've read the article in ACM Computing Surveys. > - p. 3, you lump together generic classes (as in Eiffel), container classes > (as in Smalltalk or Java) and template classes (as in C++), but these > are three completely different things. (Generics and templates are > somewhat comparable, but container classes are a separate concept that > can be realized by generics or by templates, but need not be.) > - p. 4, you give the impression that delegation is nothing more > than forwarding. You must mention that delegation can replace > inheritance only because of the way that self is bound. > - p. 9, "wholistic" -> "holistic"; "decentral" -> "decentralized"; > "some inheritance anomaly occurs" -> "some inheritance anomalies occur" > - p. 13, I am unsure how you wish to related "thread-centred" and > "object-centred" approaches to OCC and COC > - p. 13, "interdependences" -> "interdependencies" > - p. 15, "unbound queue" -> "unbounded queue" > - p. 15, what do you mean by "Delegation is hard to implement without > first class futures."? Either explain, or drop it. You haven't > properly defined delegation yet (since you didn't explain the > relationship between delegation and binding of self), so how can you > expect anyone to understand this comment? > - p. 22, the comment about constructs in italic being usable with OCC > makes no sense at all. You must explain what you mean by OCC. I've improved the text on all of the above aspects. I ignore the following three comments because the paper *has* detailed discussions of the issues that are claimed to be lacking. > - p. 25, I cannot see why you classify monitors under "implicit control". > They seem pretty explicit to me! > - p. 28, for the life of me I do not understand what you intend with > "Handshake control" > - p. 40, the comment about optimal locality mapping being NP-complete > seems neither here nor there. The question is how close you can get > in practice. > - p. 44, the language survey seems useful, but it would be really useful > if there were a web resource with the links already provided. I plan to do that, once this article is accepted. > And a few general quibbles: > - Where does Python fit into your scheme? (Python, one has to admit, > supports objects and concurrency, and is used in practice, as opposed > to many of the research languages in the survey.) done. > - You repeat essentially the same points concerning encapsulation in > the "Discussion" part of nearly every category. This gets a bit dull. I've tried to improve the discussions and to make them more readable. > Summing up, I found the survey useful and interesting, but still rather > muddled and hard to digest. I strongly encourage you to reconsider the > classification scheme and reorganize the paper. I would also strongly > recommend that you look at the Briot/Guerraoui survey, which is simpler > to understand. Perhaps that will give some hints how better to > organize the survey. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Geoffrey, now you got the history of the survey, the previous reviews, and my responses to them. I won't spam your mailbox, you can download the paper from: http://wwwipd.ira.uka.de/~phlipp/mypapers/cool-survey.ps.gz I really hope that this (much improved) survey on concurrent object-oriented languages can be published in CPE. Moreover, I really would like to get your decision soon because I'm in the process of doing my "habilitation", which is like a second PhD thesis that is required by German academic rules. But in contrast to a regular PhD thesis I can include journal publications. When accepted, I'll provide the LaTeX source of the paper of course. Regards, *Michael. PS: Please send an ack.