1. After almost 30 years of development, is there any general guideline to decide which technique is more suitable given the application (assuming that the duality holds)?
2. Is Lauer and Needham's 3rd observation (that the subsystem performance is identical across the two models) compelling?
3. How fair is the assumption that scheduling can be manipulated such that event driven models and thread driven models are identical?
4. What is the Message-Oriented dual of a context switch?
5. In transitioning from a thread oriented system to a message passing system do Lauer and Needham address the performance impact of possibly needing to package state that is local to a thread routine into a SendMessage routine? This would seem to outweigh the performance impact of a procedure call since local state is stack readable.
6. If the two approaches are duals of each others, then why is it so difficult to translate between the two?
7. This question stems from a lack of understanding on my part, but if processes are very difficult both to create and delete in a message- oriented system, how does such a system respond to changes in load if it cannot easily add or remove processes?
8. Are messages in the message-passing system processed atomically? I ask because the paper specifies on page 6 that "data structures which must be manipulated by more than one process are passed by reference in messages."
9. How would a message-passing system prioritize interrupt messages relative to other messages in a queue?
10. On page 12, the duality is succintly described at the top of the page. However, while the two models are shown to be functionally equivalent, it appears as if the message-passing method requires significantly more code to provide the same functionality as the procedure-oriented system. Is this the case in general? Does this imply that procedure-oriented systems are somewhat easier to maintain than message-oriented ones? In general, it seems that the paper focuses on the functional equivalence of the two orientations without discussing differences in ease of implementation, maintainability, and simplicity.
11. What are the difficulties implied in applying the typechecking facilities to message bodies (similar to the dual which is parameters in a procedure call) ?
12. Can you explain the performance equivalence argument?
13. Why was the duality argument so hard to believe?
14. How well does the argument apply to modern event-based vs. thread-based programming?
15. How can we compare the costs of pushing state onto the stack and popping it off, with the costs of allocating, copying and then freeing message memory?
16. It's said that choice between models is based on platform and not the application. I wanted to know which characteristics of the hardware affect this decision more? (Register count for example?)
17. The paper mentioned that the choice between message- and procedure-oriented system is determined by the machine architecture for which the system is being build. What factor of the architecture determines the operating system structure that it is suitable for? For modern operating systems like Windows or Linux where there is a large variation in the target machine, which approach should be taken?
18. Lauren and Needham based their assumption on the fact the the lower level calls for message-oriented and procedure-oriented can be implemented with identical performance. Are these valid assumption? Do they actually depend on the architecture of the underlying hardware?
19. This kind of mapping makes sense but can you also map the run-time implications of these programming styles? For example, map thread deadlocking to accidentally creating cyclic-dependencies for results from your message handlers? If you can, do you think they would end up with simmilar solutions to the problems?
20. The paper also says that deciding which style to use depends on the language and environment in which it will be used. I would say that it depends more on which implementation makes the program logic easier to read, what do you think?
21. This paper can be concluded as two OS classes are duals and one can be directly mapped to the other by replacing primitives. However, what are the factors to reply on to choose which model to adopt?
22. The idea of this paper is intuitive, but there were no formal classification or proof by the time this paper was published. Even though I do not totally agree with this paper's idea, I still wonder if there are any strong and formal proof in the past 30 years?
23. Let's review the producer and consumer problem in the thread mode. Given the primitives mapping by the paper, how to change it from thread mode to message mode? Which parts should be treated as producer, which parts should be treated as consumers, and which parts would be the protected shared area?
24. Why are two models presented in the paper duals of each other? - Are there other models different from these ones existed now?
25. The authors did not include deletion of processes and events when considering procedure-oriented and message-oriented systems. Do you think a duality could be achieved with deletion of threads, not only in the logical sense but also in the performance sense?
26. The authors claim in third paragraph to the end of page 14 that sending a message in message-oriented system involves a computation of the same complexity as FORKing to an ENTRY procedure. Would you say that the system architecture has a vote in this? How would you comment on the authors' above claim after looking at the authors' statement on the page 15, first paragraph: "In general, we have observed that a message-oriented operating system kernel implemented by a dedicated team on a friendly machine .... But we have also observed that the same is true for a procedure-oriented system if the machine architecture is appropriate for that."
27. Why does simple resource manager for message-oriented system enqueue port2 onto the set of ports if portId k is received from a call to WaitForMessage(.) function? I am lost on this one?
28. The mapping table in the page 12 seems to overlook the data aspects only by focusing the procedures aspects. Thus, I still believe that two programming models are different in a critical way: how to treat data; while threads use the shared memory, events carry their messages. Would you give your opinion for that?
29. Could be there ideal machine architecture to support two programming models equally? Though the paper introduces machine architecture for each model in the page 17, it is too brief to understand overall factors.
30. The paper suggests that the flow control constructs (events vs. threads) are of similar complexity. Yet the recent paper (#6) suggested that properly implemented, threads can be faster by removing O(n) aspects of scheduling. Does this paper still stand up if their argument of similar complexity no longer holds?
31. The argument in the paper for duality seems to rest on the fact that if you respect certain constraints, the textual representation of programs written in events vs. threads are similar. This seems like an extremely weak argument. To me it seems that control flow constructs are a relatively small percentage of code. Is there another way to make a stronger argument for duality?
32. The argument of threads and events, which this paper essays to resolve, is still quite a hot topic, as 16,300,000 hits from Google on events vs. threads would indicate, which each side trying to convert the other. One question that always seems to come to mind is "Why bother?" Given a suitable layer of abstraction, does it really matter if the guy who wrote it used threads of events, as long as the bloody thing works like it should?
33. There is a scolding tone in the paper, in which the authors basically chastise people for being so emotionally involved with what should be a "purely technical issue". What was the environment in the systems design scene at the time of the paper's writing that deserved such action? Were computer scientists receiving death threats if they don't stop using threads/events/whatever or something?
34. Concerning the conclusion section of the paper:
The conclusion that can be drawn from the authors' exposed canonical models and observations is that there is no inherent difference between the 2 styles of system design or the programs that use them, at least in the domain of performance. The authors claim that in the end, the main factor that makes one design (message-oriented system, or procedure-oriented system) more attractive than the other is the design decisions that were taken for the system on which process and synchronization facilities are to be built. Could we interpret that to mean that for a given system (hardware,OS,programming language), one model should always be preferable to use (more efficient) than the other ?
36. The paper's perspective seems interesting. It mentions that the hardware
architecture may have some influence on whether one of the two styles
would be more favourable than the other. Are today's machines so homogeneous
that this is not as big of a factor anymore? Given that today's machines
are going down the road of multi-cores, would you think that message passing
will be a more favourable style?
37. In the discussion about the differences between the styles, it mentions that
on the first-order consideration, the two styles are the same. What do you
think the 2nd and 3rd order considerations (which seemed to have been just
handwaved) should be?
38. In overloaded conditions (not much free memory, many processes), will the
message-oriented or procedure-oriented system perform better?
39. Message-oriented system is characterized by facilities for passing
messages easily and efficiently among processes. Are these passed
messages the same as resource shared by processes?
40. Procedure-oriented system is characterized by a protection and
addressing mechanism oriented toward procedures. Is a procedure
equivalent to a synchronized block such as in Java?
41. I want to know what is your idea about this paper. In fact, before
reviewing this paper, I think the two schemes could replace with each
other if we just consider function instead of other factors, such as
performance and etc. I think the most important thing for us to know is
under what kind of conditions we should prefer one scheme to another.
42. Could you classify Linux and Solaris into the two categories ? Just
do some simple analysis.
43. Where do threads fit in into the given canonical models ?
44. How valid is the assumption - that a procedural program will have
such a well defined and easily decomposable structure ?
45. Are monitors the right abstraction for representing procedural
elements?
46 what about the psychological effect of imposing a certain model on the
programmer?
47. I would imagine that the *explicit* handling of events would cause the
programmer to think more about concurrency (e.g. not locking resources
too casually).
48. Do you think that the lower number of process (heavy) context switches in messages passing (event driven) model balances its performance with the higher number of lighter context switches in the case of procedural (threads) model?
49. In paper #4, it was said that threads were a bad idea except maybe in true concurrency applications like scientific experiments. What is true concurrency? I mean I thought that threads would be a good idea if there was a central data store which needed to be accessed concurrently. But can’t that be modeled using message passing too? With a message being passed with reference to the data?
We focused on the performance issues proposed by the paper. One question concerned was whether the authors` claim about a friendly architecure was contradicting the performance equivalence claims. However the authors are claiming that the complexity of the dual programs wouldn`t change even though on different architectures the performance might be different.This brought a new question on what is a friendly architecture and how fair to rely our on these architectures but we agreed that the architectures were not very general in those days.
One other question was whether the performance issues and duality arguments would hold even if we used different APIs for the two models. The question is a bit hard to answer because different APIs might have brought different complexities. However one thing even today holds is that distributed systems(for message passing e.g: MPI) and also Windows have similar APIs to those given in the paper. Hence the concern about different APIs can be deferred.
Another question was about the usage of monitors in this paper: It was a misunderstanding on how the monitors used for the resources. Basically a different monitor is used for every shared resource.
Another concern was raised on the similarity of the message-oriented systems and event systems. We again agreed that there`s enough evidence on this similarity: such as explicit messaging between processes, message driven pre-emptive system. However there are still some differences between most event-driven systems and the message-oriented system proposed such as: cooperative scheduling and shared memory usage in event systems.
Discussion Recap