Hi All, This seems to be a continuation of discussion(s) I had some time ago with Teig. See e.g. http://oyvteig.blogspot.be/2009/02/007-synchronous-and-asynchronous.html I fully agree with the concept of WYSIWYG semantics, but the processes and channels are insufficient for the real world. The main reason is that the CSP processes and channels are the primitive concepts whereas real world systems have more complex behaviour that often makes the underlying primitives invisible. Therefore we opted to speak of "interactions" and "entities". The point is that on has to make the semantics of the interactions explicit to get the WYSIWYG experience. The latter means that the representation (e.g. in the software) is close to what we want to model. A typical interaction will be composed of 2 primitive interactions, e.g. a request and an ack, as well as on the "sender side" as on the "receiver side". This is the CSP synchronisation and in the formal sense the guard. An additional element is the action taking place after the synchronisation. This can be something very simple like continuing the process thread but also something a lot more complex like passing and buffering some data and then broadcasting it over a network, etc. A big part of the discussion with Teig was about the fact that this introduced asynchronous semantics. The point is that the asynchronism is strictly bounded (e.g. FIFO is full) and then we fall back on a synchronous behaviour. Note that this can be done in pure CSP primitives as well, but then one needs at least one intermediate process (e.g; doing the buffering) and additional channels (e.g. to mimic the acks). This complexity makes the application level semantics hard to see. But a picture is worth a 1000 words. So I have attached a screenshot on a demo application of OpenComRTOS. Tasks correspond to processes and they interact through so-called Hubs in which the Tasks synchronise. For example the Port Hub allows to exchange Packets between Tasks and is the closest to a typical CSP channel (as the Packets have no semantics themselves). The canvas also shows Hubs like an Event (synchronisation on a Boolean condition) and a Memory Pool with the possible interactions (in this case allocating a block of memory whereby the programmer has 3 options: Waiting (blocking in the CSP sense), Non-Waiting (basically test and return) or Wait with a Time-Out). The same principles were applied to interact e.g. with a host-node (a PC screen) whereby the Task can e.g. put some text or graphics on the screen. Additional note: while the application graph is created by the developer, once the source code is created, the graph is obtained by parsing the source code, hence WYSIWYG is what the program says. Best regards, Eric Verhulst From: Mailing List Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Teig, Oyvind CCS An important quality in trying to “sell” channels is WYSIWYG semantics, first coined so by Peter Welch, I believe, in a letter signed by some of us in 1997 [1]. (Is there any other trace on the net of anything eralier?) Over the years I have tried to show how the SDL [2] type send and forget methodology does not have WYSIWYG semantics and how that relates to maintenance and hidden type of errors etc. I have tried to blog about it [3]. Reading that again now I wonder if this statement is correct: “If the client sends into a buffered channel, it's still WYSIWYG, since the channel pipe disregarding size is process to process.” I struggle with tagging WYSIWYG semantics to something: 1. Synchronous non buffered channel (ok). 2. Safe process-process that sooner or later synchronizes / buffered channel (ok). 3. Send and forget into potentially infinite buffer pool with one input path only (many-one) (not WYSIWYG). a. Same but with application acknowledge messages always (ok). b. Same but with return false from MessageSend if buffer pool is full (then polling, since no XCHAN) (not WYSIWYG). Is there a simple way to describe which paradigm has WYSIWYG semantics and which does not? [1] - 1997 letter to Edward A. Parrish The Editor IEEE Computer, see http://web.archive.org/web/19991013044050/http://www.cs.bris.ac.uk/~alan/Java/ieeelet.html (just wait, it will appear) [2] – SDL http://en.wikipedia.org/wiki/Specification_and_Description_Language [2] – http://oyvteig.blogspot.com/2011/12/036-wysiwyg-semantics.html (Mr) Øyvind Teig Senior development engineer, M.Sc. Autronica Fire and Security AS UTC CCS EMEA Fire & Security Operations Tel: +47 7358 2468 oyvind.teig@xxxxxxxxxxxxxxxx http://www.autronicafire.no/ http://www.teigfam.net/oyvind/work/work.html |
Attachment:
Wysiwyg_semantics.png
Description: PNG image
