From: Claus Reinke To: designCPN@daimi.aau.dk Date: Thu, 28 Nov 1996 16:16:48 +0100 (MET) Subject: Re: Communication with external processes This message is an attempt to improve on my use of terminology which has turned out to be too lax for a discussion of the problems involved. In my previous messages I just equated place-based with asynchronous communication and transition-based with synchronous communication and suggested that at least synchronous external communication was correctly implemented by the current system. > > communication | asynchronous synchronous > --------------+-------------+------------------- > internal | standard research topic > external | ??? implemented > However, this isn't (quite) correct. In particular, one has to be careful when using the term synchronous communication in connection with the currently implemented form of transition-based communication via SML's side-effecting i/o-primitives. synchronous communication: producing and consuming the communicated data happens in one step asynchronous communication: producing and consuming the communicated data proceeds in several steps In a correct implementation of synchronous external communication, a transition depending on i/o-operations would only be enabled if its communication partners were so, too (so that they may fire synchronously). Thus, non-blocking i/o would be guaranteed and the availability of input data/buffer space for output data would influence the enabling of those transitions depending on i/o-operations (instead of possibly blocking the whole net). For the current implementation, using input or output in a transition code region may be synchronous or asynchronous, depending on the internal buffering used by SML's i/o operations. The very same transition may perform output without blocking in one step and may block (the whole net) in the next step (while waiting for the output buffer to be read by an external process). In the opposite case, a transition depending on input operations may fire without blocking or block while waiting for input to arrive. Depending on conditions external to the net models, the current implementation can be described as supporting a kind of mostly asynchronous output (assuming large buffers and rather fast reading external processes) combined with a form of input that forces synchronization by chance (feasible only if the model can exactly predict the order of external events which is unlikely for concurrent systems). However, there is currently no way to control these synchronization properties in Design/CPN. The only work-around seems to be the simulation of busy-waiting by transitions that are always enabled. When firing, they test whether non-blocking i/o is possible and, depending on the test results, produce/consume tokens or not. In view of the above, the current situation is better described as: communication | asynchronous synchronous indefinite --------------+-------------+--------------+------------ internal | standard research topic prohibited external | ??? ??? implemented > Ultimately, it would be nice to have both asynchronous and synchronous > communication facilities on both levels, so that the one most suitable > for the problem in question could be used for modeling. This still holds, but the design and implementation of at least one of the alternatives (asynchronous/synchronous external communication) becomes even more urgent since every model using the current 'features` for external communication stands on shaky grounds. -- Claus Reinke University of Kiel email: cr@informatik.uni-kiel.de Department of Computer Science http://www.informatik.uni-kiel.de/~cr/ Preusserstr. 1-9, 24105 Kiel --- [[ Post messages and summary of replies: designCPN@daimi.aau.dk ]] [[ To (un)subscribe, send "help" to: Majordomo@daimi.aau.dk ]] [[ The moderator's address: designCPN-owner@daimi.aau.dk ]] [[ World Wide Web URL: http://www.daimi.aau.dk/designCPN/email/ ]]