XCHAN "XCHANs: Notes on a New Channel Type" 1 CPA-2012 - - PowerPoint PPT Presentation

▶
xchan
SMART_READER_LITE
LIVE PREVIEW

XCHAN "XCHANs: Notes on a New Channel Type" 1 CPA-2012 - - PowerPoint PPT Presentation

Oct 14, 2022 603 likes •1.18k views

XCHAN "XCHANs: Notes on a New Channel Type" 1 CPA-2012 at Abertay University Dundee, Scotland yvind Teig Autronica Fire and Security Trondheim, Norway http://www.teigfam.net/oyvind/pub/pub_details.html#XCHAN

slide-1
SLIDE 1

"XCHANs: Notes on a New Channel Type"

XCHAN

1

slide-2
SLIDE 2

CPA-2012 at Abertay University Dundee, Scotland

Øyvind Teig Autronica Fire and Security

Trondheim, Norway

http://www.teigfam.net/oyvind/pub/pub_details.html#XCHAN http://wotug.org/paperdb/

Version 28. Aug.2012 07:29 (55 incremental pages) 2

slide-3
SLIDE 3

XCHAN = x-channel + CHAN

x-channel CHAN

3

slide-4
SLIDE 4

Background

  • From discussions at Autronica
  • Not implemented
  • Goal for me was to try to merge asynchronous and

synchronous "camps"..

  • ..to arrive at a common methodology
  • To make it "easier" to comply to SIL (Safety Integrity

Level) approving according to IEC 61508 standard for safety critical systems

  • Assumed implementation loosely based on implemented

ideas with EGGTIMER and REPTIMER. ([9] CPA-2009 paper)

4

slide-5
SLIDE 5

XCHAN (100) OF BYTE my_xchan:

asynchronous, nonbuffered

5

slide-6
SLIDE 6

XCHAN (100) OF BYTE my_xchan:

asynchronous, buffered

6

slide-7
SLIDE 7

XCHAN (...) OF BYTE my_xchan:

Sender is notified as to its success or "failure"

7

slide-8
SLIDE 8

XCHAN (...) OF BYTE my_xchan:

Sender is notified as to its success on return of send:

  • data moved to buffer
  • data moved to receiver

8

slide-9
SLIDE 9

XCHAN (...) OF BYTE my_xchan:

Sender is notified as to its "failure" on return of send:

  • buffer full
  • receiver not present

9

slide-10
SLIDE 10

XCHAN (...) OF BYTE my_xchan:

Sender is notified as to its "failure" on return of send:

  • buffer full
  • receiver not present

It always returns!

10

slide-11
SLIDE 11

If "failed" to send on XCHAN:

11

slide-12
SLIDE 12

If "failed" to send on XCHAN: "Not sent" is no fault!

12

slide-13
SLIDE 13

If "failed" to send on XCHAN: "Not sent" is no fault! But a contract to send later

13

slide-14
SLIDE 14

If not sent on XCHAN:

  • listen to x-channel (in an ALT or select)
  • resend old or fresher value when it arrives
  • this send will always succeed

14

slide-15
SLIDE 15

If not sent:

  • listen to x-channel (in an ALT or select)
  • resend old or fresher value when it arrives
  • this send will always succeed

"channel-ready-channel"

15

slide-16
SLIDE 16

If not sent:

  • listen to x-channel (in an ALT or select)
  • resend old or fresher value when it arrives
  • this send will always succeed

This contract (design pattern) between sender and receiver must be adhered to

16

slide-17
SLIDE 17

17

All said! The rest is really rationale and

slide-18
SLIDE 18

Send and forget

Tradition

18

slide-19
SLIDE 19

Send, if not sent then don't forget x-channel

New

19

slide-20
SLIDE 20

Send, if not sent then don't forget x-channel Send and forget Asynchronous Asynchronous

20

slide-21
SLIDE 21

Send, if not sent then don't forget x-channel Send and forget Asynchronous Asynchronous Restart if buffer overflow (bridge metaphor: collapse) Full flow control (bridge only ever full)

21

slide-22
SLIDE 22

Send, if not sent then don't forget x-channel Send and forget Asynchronous Asynchronous Restart if buffer overflow (bridge metaphor: collapse) Full flow control (bridge only ever full) ..finding "enough" buffer size..

22

slide-23
SLIDE 23

Send, if not sent then don't forget x-channel Send and forget Asynchronous Asynchronous Restart if buffer overflow (bridge metaphor: collapse) Full flow control (bridge only ever full) Forget means no application handling Full application handling (but don't forget x-channel)

23

slide-24
SLIDE 24

Send and forget Asynchronous Restart if buffer overflow (bridge metaphor: collapse) Forget means no application handling Those programmers..

24

slide-25
SLIDE 25

Send, if not sent then don't forget x-channel Send and forget Asynchronous Asynchronous Restart if buffer overflow (bridge metaphor: collapse) Full flow control (bridge only ever full) Forget means no application handling Full application handling (but don't forget x-channel) Those programmers.. ..could love this..

25

slide-26
SLIDE 26

Send, if not sent then don't forget x-channel Send and forget Asynchronous Asynchronous Restart if buffer overflow (bridge metaphor: collapse) Full flow control (bridge only ever full) Forget means no application handling Full application handling (but don't forget x-channel) Those programmers.. ..could love this.. ..merging asynchronous and synchronous traditions

26

slide-27
SLIDE 27

27

XCHAN is a new tool (in the not empty toolbox!)

slide-28
SLIDE 28
  • 1. buffering on-the-way:
  • a. after send-and-forget (asynchronous only, no flow control)
  • b. inside a buffered channel (asynchronous until full, then

blocking)

  • c. inside a buffered XCHAN (asynchronous until full, then wait for

ready)

  • 2. buffering inside a process (task, thread, …) combined with:
  • a. no buffering on-the-way with zero-buffered channel

(blocking synchronous, communication by synchronisation)

  • b. buffering on-the-way, see bullets 1a or 1b above
  • c. no buffering on-the-way with zero-buffered XCHAN

(ready synchronous or wait for ready)

  • 3. no explicit buffering at all (with zero-buffered channels)

Buffering (or not)

28

slide-29
SLIDE 29

Something old, something new, something borrowed, something blue - and a sixpence in her shoe..

CSP CHAN unix pipe ewouldblock select

"If further events are to be possible (such as a channel which can report on whether or not the channel is empty) …" Schneider [10]

flow control

XCHAN

29

slide-30
SLIDE 30

CSP CHAN unix pipe ewouldblock select

  • utput guards

"If further events are to be possible (such as a channel which can report on whether or not the channel is empty) …" Schneider [10]

flow control

XCHAN

Something old, something new, something borrowed, something blue - and a sixpence in her shoe..

30

slide-31
SLIDE 31

Output guard and/versus XCHAN

XCHAN Output guard

Never blocks May block Would have blocked is explicit One taken, which others could have? Next is sure Next is attempt and part of ALT Commit to send, not what to send ALT commits to what to send Commitment is state No such state

31

slide-32
SLIDE 32

Output guard and/versus XCHAN

XCHAN Output guard

Never blocks May block Would have blocked is explicit One taken, which others could have? Next is sure Next is attempt and part of ALT Commit to send, not what to send ALT commits to what to send Commitment contains state No such state A priori = "first order" A posteriori = "second order"

32

slide-33
SLIDE 33

Do observe the source of the x-channel is the run-time system, as for a "timeout-channel"

33

slide-34
SLIDE 34

Architectural leak is when application code is added (made more complicated) to compensate for missing features at link level Extra processes Extra channels Busy polling Shared state ...

34

slide-35
SLIDE 35

When Server S cannot get rid of this data, it can still input more, and finally send newer data Fast producer, slow consumer and XCHAN

35

slide-36
SLIDE 36

Figure 1. Example of an overflow buffer (OBUF)

"Traditional" solution

36

slide-37
SLIDE 37

Figure 2. Buffered XCHAN, as shown in Listing 1 (below)

An XCHAN solution

37

slide-38
SLIDE 38

Listing 1. Overflow handling and output to buffered channels (ANSI C and macros)

01 while (TRUE) { 02 ALT(); 03 ALT_SIGNAL_CHAN_IN (XCHAN_READY); // data-less 04 ALT_CHAN_IN (CHAN_DATA_IN, Value); 05? ALT_END(); // Delivers ThisChannelId: 06 07 switch (ThisChannelId) { 08 case XCHAN_READY: { // sending will succeed 09! CP->Sent_Out = CHAN_OUT (XCHAN_DATA_OUT,Value); 10 } break; 11 case CHAN_DATA_IN: { 12 if (!CP->Sent_Out) { 13 ... handle overflow (decide what value(s) to discard) 14 } 15 else { // sending may succeed: 16! CP->Sent_Out = CHAN_OUT (XCHAN_DATA_OUT,Value); 17 } 18 } break; 19 _DEFAULT_EXIT_VAL (ThisChannelId) 20 } 21 }

An XCHAN solution (code)

38

slide-39
SLIDE 39

Figure 3. Zero buffered XCHAN

Another XCHAN solution

39

slide-40
SLIDE 40

XCHANs as tool to break deadlock cycles

40

slide-41
SLIDE 41

Figure 4. Traditional "knock-come" pattern

"Knock-come"

41

slide-42
SLIDE 42

Figure 5. Same pattern with XCHAN

Knock-come(?) with XCHAN

42

slide-43
SLIDE 43

Figure 5. Same pattern with XCHAN

Knock-come(?) with XCHAN No need to think about knock-come, it comes for free!

43

slide-44
SLIDE 44
  • XCHAN sending could return more than "sent" / "not sent"

(like "percentage full")

  • x-channel could deliver more than "ready"

(like "closed")

Extending XCHANs

44

slide-45
SLIDE 45
  • XCHAN sending could return more than "sent" / "not sent"

(like "percentage full")

  • x-channel could deliver more than "ready"

(like "closed")

Extending XCHANs

45

slide-46
SLIDE 46
  • XCHAN sending could return more than "sent" / "not sent"

(like "percentage full")

  • x-channel could deliver more than "ready"

(like "closed") From runtime system, (not process)?

Extending XCHANs

46

slide-47
SLIDE 47
  • XCHAN that sends immediately has standard channel

semantics

  • x-channel has standard channel semantics
  • Triggering of x-channel and intermediate blocking in

receiver before sender do send, probably cannot be modeled in CSP , and needs help from runtime system. That was at paper

  • time. We now know better: stay tuned

Semantics and implementation

47

slide-48
SLIDE 48

Appendix

Code courtesy of golang-

48

slide-49
SLIDE 49

Figure 6. Go example (right channel capacity irrelevant

Go has output guards

49

Appendix

slide-50
SLIDE 50

Listing 2. Managing without xchan in Go with goroutines

01 func Server (in <-chan int, out chan<- int) { 02 value := 0 // Declaration and assignment 03 valid := false // --“-- 04 for { 05 outc := out // Always use a copy of "out" 06 // If we have no value, then don't attempt 07 // to send it on the out channel: 08 if !valid { 09 outc = nil // Makes input alone in select 10 } 11 select { 12? case value = <-in: // RECEIVE? 13 // "Overflow" if valid is already true. 14 valid = true 15! case outc <- value: // SEND? 16 valid = false 17 } 18 } 19 } 50

Appendix

slide-51
SLIDE 51

51

Appendix Another code example also shown in paper There, sender empties receiver end!

  • if channel is seen to be full,
slide-52
SLIDE 52

Send to itself?

We have not studied whether bufgered XCHAN could be wrapped into the sending process, enabling the process to send to itself - but we think this is possible

52

slide-53
SLIDE 53

Modeling XCHAN

53

Finall

slide-54
SLIDE 54

Modeling XCHAN

  • Model of bufgered XCHAN in occam-pi
  • Model of unbufgered XCHAN in occam-pi
  • Done as a feasability study by the editor
  • f the paper, Peter H. Welch, during and

after the editing

Courtesy

54

slide-55
SLIDE 55

Thank you!

55

¿questions?

slide-56
SLIDE 56

Three pictures: Vemork hydroelectric plant Rjukan (1911), now the Norwegian Industrial Workers Museum (2012) First page: Drammen signal box (1910), now at the Railway Museum at Hamar Small toolbox that I made for Isac 56