Or must you know just a little about that process, and that process? But not aware of the costs? That life is at stake?
Note
I have written something about this in a paper, where I tried to define a new term. I called it the "Office Mapping Factor" [1]. A friend computer scientist said it was the "coolest" thing I had done. (He might not be aware of this or this.) Here is the abstract of [1]:
This case observation describes how an embedded industrial software architecture was “mapped” onto an office layout. It describes a particular type of program architecture that does this mapping rather well. The more a programmer knows what to do, and so may withdraw to his office and do it, the higher the cohesion or completeness. The less s/he has to know about what is going on in other offices, the lower the coupling or disturbance. The project, which made us aware of this, was an embedded system built on the well-known process data-flow architecture. All interprocess communication that carried data was on synchronous, blocking channels. In this programming paradigm, it is possible for a process to refuse to “listen” on a channel while it is busy doing other things. We think that this in a way corresponds to closing the door to an office. When another process needs to communicate with such a process, it will simply be blocked (and descheduled). No queuing is done. The process, or the programmer, need not worry about holding up others. The net result seems to be good isolation of work and easier implementation. The isolation also enables faster pinpointing of where an error may be and, hence, in fixing the error in one place only. Even before the product was shipped, it was possible to keep the system with close to zero known errors. The paradigm described here has become a valuable tool in our toolbox. However, when this paradigm is used, one must also pay attention should complexity start to grow beyond expectations, as it may be a sign of too high cohesion or too little coupling.I will not repeat [1] here, but I see no reason to rephrase this, from chapter 3 point 1:
For a process, not being able to control when it is going to be used by the other processes. Serving “in between” or putting calls in a local queue makes it much more complicated to have “quality cohesion”. [Java classes, for example, cannot prevent their methods being called (except, through ‘synchronized’, where other synchronized methods can't run if one is already running). But that does not prevent the method from happening. It just delays it. It cannot be stopped, even if the object is not in a position to service it (like a "get" on an empty buffer). Not being able to control when it may be used by other processes means that things of importance to a process may change without it being aware of it. This trait is further discussed here, since the other points (below) only to a small degree are valid in our project.]I also have written about WYSIWYG semantics at my note 007 - Synchronous and asynchronous.
Origins
The term WYSIWYG semantics seems to stem from [2]:
One crucial benefit of CSP is that its thread semantics are compositional (i.e. WYSIWYG), whereas monitor thread semantics are context-sensitive (i.e. non-WYSIWYG and that's why they hurt!). Example: to write and understand one synchronized method in a (Java) class, we need to write and understand all the synchronized methods in that class at the same time -- we can't knock them off one-by-one! This does not scale!! We have a combinatorial explosion of complexity!!!
With CSP, threads can refuse individual events if they are not in a state to accept them. They do not wait on shared condition variables and do not rely on other methods to fix things up for them. Each method has its own contract and looks after itself. This type of logic does scale.Practical example 1: A server having a session with one of several clients
There are five clients, named A-E and one server S. Helper process for S is called H
Server process S (easy case)
- Client A send a message service request to S
- S needs services from H, so this will take a while
- S waits for response from H in a select
- S receives response from H (from nowhere else)
- S sends reply back to client A
- S listens in a fair way on client channels (pipes etc.), and receives a request from client B
A possible architecture could be one point-to-point channel (or p-p pipes) between each client and the server, and two p-p channels between S and H (request and response).
Server A could have done something else in the meantime, it didn't have to just wait for reply from S. This could have been more or less easy, see later.
Server process S (difficult case)
Client A send a message service request to S
Server process S (difficult case)
Client A send a message service request to S
- S needs services from H, so this will take a while
- S waits for response from H in a select
- S receives instead of response from H, another service request from client B
- S pushes this request away (luckily this was the only request)
- S finally receives response from H
- S sends reply back to client A
- S pops request from client B and processes it
This is not WYSIWYG semantics.
An architecture that could cause this to happen is a common message queue that the run-time system uses to pick new messages from, to the server. At any time, any client could send requests into this common queue.
Client processes
So far we have not said anything about the client processes. Does it make any difference if they block or send and forget the request into (an infinite) queue?
A WYSIWYG scenario: If the first request blocks immediately (zero buffered channel), and the server not at this channel yet or in fact is at this channel, then the request - reply sequence will be "atomic" as seen from the outside. If several clients all try to send a request at the same time: still as "atomic". We can knock them off one-by-one! This scales!
If the client sends into a buffered channel (see note 034), it's still WYSIWYG, since the channel pipe disregarding size is process to process. Not shared. Even the Any2OneChannel of JCSP [3] will be fine, since:
Any2OneChannel is an interface for a channel which is safe for use by many writing processes but only one reader. Writing processes compete with each other to use the channel. Only the reader and one writer will actually be using the channel at any one time. This is managed by the channel – user processes just read from or write to it.What WYSIWYG does not cover
Please note that this is a safely shared channel and not a message gatherer. Currently, gathering has to be managed by writing an active process.
I don't think that this term would cover problems like race conditions, hazards, deadlock, livelock, starvation, pointer errors or anything causing "segment fault". Even if one do get something else than you see, to me the term What You See Is What You Get semantics would not cover these matters.
They belong to different "error spaces".
Communication with the "Nonstop technobabbel" blog
I wrote a comment (here) to Svein Arne Ackenhausen's blog note "Parallel takes you half the way."
He responded by making a new note to discuss my comment, see "2 cups of messaging, 1 tablespoon of async and a whole lot of context".
I then responded with a rather large reply to this, here.
Very interesting, indeed! Thank you!
References
[1] - "High Cohesion and Low Coupling: the Office Mapping Factor". Read at http://www.teigfam.net/oyvind/pub/pub_details.html#TheOfficeMappingFactor
[2] - Letter to Edward A. Parrish, The Editor, IEEE Computer. Peter Welch (University of Kent, UK) et al. (Dead url: http://www.cs.bris.ac.uk/~alan/Java/ieeelet.html (1997)). Internet archive at http://web.archive.org/web/19991013044050/http://www.cs.bris.ac.uk/~alan/Java/ieeelet.html (1999)
[3] - org.jcsp.lang Interface Any2OneChannel, see http://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-1.1-rc4/jcsp-doc/org/jcsp/lang/Any2OneChannel.html (part of Communicating Sequential Processes for JavaTM (JCSP) at http://www.cs.kent.ac.uk/projects/ofa/jcsp/)
.
.
0 comments:
Post a Comment