Øyvind Teig
Tech posts by aclassifier
Also see Designer's note page
Archive by month and about me: here
Last edit: 4Sept2015
Started move: September 2012
All updates at http://www.teigfam.net/oyvind/home/, but the overview is updated
Wednesday, April 18, 2012
045 - A nondeterministic note about nondeterminism
Wednesday, March 21, 2012
044 - Is (x < (x+1)) really always true?
- Update (16Sept2015): New blog note, similar theme: Know your timer's type
- Update (12April2012): one of the compiler vendors mentioned below has admitted to consider to make the compiler generate a #warning for the dead code examples here! So maybe it is possible to change the world, just a little?
typedef signed char int8_a; typedef unsigned char word8_a; typedef unsigned short word16_a; #define MAX 300 word16_a cnt; { // -------- signed -------- { int8_a x = 0; cnt = 0; // while (cnt < MAX) { if (x < (x+1)) { cnt = cnt + 1; } else { cnt = MAX; // BP1 } x = x + 1; // } } // -------- unsigned -------- { word8_a x = 0; cnt = 0; // while (cnt < MAX) { if (x < (x+1)) { cnt = cnt + 1; } else { cnt = MAX; // BP2 } x = x + 1; // } } } | // Øyvind Teig // Trondheim // Norway // // { // -------- signed -------- { int8_a x = 0; int8_a y = 1; cnt = 0; while (cnt < MAX) { if (x < y) { cnt = cnt + 1; } else { cnt = MAX; // BP3 } x = x + 1; y = y + 1; } } // -------- unsigned -------- { word8_a x = 0; word8_a y = 1; cnt = 0; while (cnt < MAX) { if (x < y) { cnt = cnt + 1; } else { cnt = MAX; // BP4 } x = x + 1; y = y + 1; } } } |
A signed number would wrap around when "1" is added to it, from most positive 127 to most negative -128 (assuming 8 bit basic word length in these examples). An unsigned would wrap from its most positive 255 to 0. You must define the int.. and word.. types for yourself, and be sure that there is a greater value around it this would stop the loop (like my 300, which is more than 255 anyway). I do this so that I only have one complex ball in the air at a time. Research tries to divide and conquer.
Since 127 is not less than -128 (top left and right code - it's greater!) and 255 is not less than 0 (bottom left and right code - it's also greater!), my compiler should make the program hit the four breakpoints BP1-BP4 in turn. Right?
Not my compiler, optimized code or not! The program only hits BP3 and BP4! In the rightmost code, the variable "y" runs before "x" by "1", so all is fine. But in the leftmost code, the variable "x" incremented in the expression as "x+1" causes the compiler to get it wrong!
I tried to take control of the value "1" that's added by making a variable "one" with value "1" as signed or unsigned, but it did not help. I tried two variables that followed each other and "x < (y+1)", but it did not help. Finally I tried "(((x+1)-x)>0)", but still I never hit the false branches BP1-BP4!
Compilers
I compiled with the IAR compiler for an eight bit machine. We also compiled with gcc on Linux, and it's the same. I ran a test with static analysis tool QA·C from Programming Research with rather strict "personality", and it did not complain. I have not tested with PC-Lint.
The "excuse"
Of course there is an "excuse" for this in the C compiler world. How an expression is internally evaluated is not the programmer's business. He doesn't own the expression. This is so by language design.
So, if they use 16 bits to evaluate an 8 bit expression (there is nothing like an "8 bit expression", it's "their any-bit expression"), then it would not wrap around from 127 or 255, but get straight into 128 or 256. If there is width enough. But they will sooner or later get another semantics from the same syntax, as widths go from 8 to 16 to 32 to 64 - and wrap around is or is not inevitable!
(How about type casting inside the expression? In this case I could try to, but I would still have to test to know what happens - hugely unnecessary in 2012, almost 50 years after Fortran. WYSI-not-WYG! And besides, I had already used typed variables into the expression)
(This remembers me of a situation where I was going to make a single-bit mask by shifting into a word8, 16 or 32. In order to make a macro work, the one'er that I had to use was required to be typecast to a long. So the macro became #define MASK_F(c) (1L << c), observe the 'L'. The standard seems to state that it is supposed to be like this. The long typecast was required for the 32-bit mask, and did not hurt for the other masks. I wonder why this is intelligent language design)
Back to the not hitting false issue. There is a serious cognitive problem also here. Any programmer relates to word widths. They are always finite, like a ruler inside our heads, from one ear to the other.
We should hit all those breakpoints! But the state of the art is that we might probably not get there.
We would never know, a priori. But this is as precise as it gets: we'd have to think about this expression is a bubble.
(PS, if you are still with me. My starting sentence "Even if the value one added to any number is always greater than the number itself" is about as precise as I could make it..)
.
Wednesday, March 7, 2012
043 - Scratching my head with their HATS
[8March2012: This note became unmanagable for me, so I have parked it for the time being. I'll apply for a refill of brains and maybe come back. Sorry]
[Lots of words here that I have removed and saved but perhaps may come back to. If you look at some of the references you may get an idea why I thought it difficult to extract concurrency related features. This is very comprehensive stuff!]
[2] - http://www.teigfam.net/oyvind/pub/pub
[7] - http://www.hats-project.eu/sites/default/files/Deliverable25.pdf -" Deliverable D2.5- Verification of Behavioral Properties"
Monday, February 27, 2012
041 - Know your timer's types
Saturday, February 4, 2012
040 - Amateur publishing for real
- Fit to frame (tick on or off: I did off) ("Tilpass bilde til rammestørrelse" in Norwegian)
- Moving picture around by hand (I did push to right on right pages and push to left on left pages)
- I write the book in Pages on a Mac. I use page layout when the goal is paper or pdf. Page size 20 cm width x 15 cm height, since that's one of the formats that iPhoto book has. The picture above shows that the physical book I got back was 19.5 x 15.2 cm.
- I export to pdf, best quality. I get one pdf.
- I open this pdf in GraphicConverter as 400 dpi and export from GC. It will make jpg of all my pages in one batch. (In 2008 I could export directly from Pages to iPhoto, but it only yielded 200 dpi, which was not good enough for the 10 point text. Also, Preview for Lion does export to jpg any dpi you like, but only one page at a time).
- I import all my jpg images of my book pages to iPhoto. It has no idea that this is a book with short stories.
- I build the book and order it. This book uses formal layout and 20x15 cm softcover. But before that I iterate too many times, hence the figure above. The figure really says everything valid for my last order, the way it's described above.
- To iterate I use archive book as pdf from iPhoto (one pdf), and export as jpg (one jpg per page). I study and try and study. Next time I'll reread this blog note!
- There is no title on the spine. I assume the books Apple produces often are too thin, so it's difficult to get the title correctly aligned at that cost.
- The rear cover has a defined format, with one or two predefined windows (one for bitmap and one for text, see next figure). The rest of the structure may be defined by a few choices. I assume it's because letting me do the rear cover myself with include knowledge of how thick the back (book) is.
- Reported to http://www.apple.com/feedback/pages.html on 22Feb2012
- I also informed about this blog note at https://discussions.apple.com/thread/3755214.
Monday, January 30, 2012
039 - Adding real-time processes to on/when programming?
- A process is a C function. Start all process names with P_.
- Make a list of pointers to those functions.
- No static variables in the functions.
- No reference to external variables except the channels it uses.
- A channel sends data and is basically blocking. The second on the channel (sender or receiver) continues to run, while the first becomes ready.
- A channel sends signals (with no data) asynchronously (never blocks).
- A buffered channel never blocks, but always returns an ok/full bool. When it's full the scheduler uses a channel ready signal channel to tell that the channel again may be sent to
- A channel input may define three types of timers: ALTTIMER, EGGTIMER and REPTIMER.
- If you need to pass parameters to a function, there is no way to do it in C. Since it's going to be called by its pointer when it's scheduled, adding parameters may be done with some kind of table. But this is most often not needed for a small scheduler in C. Since there is no language support, it's possible to get around it.
- ...
- You need a standard scheduler in C, that keeps a list of the entry points to all processes. The entry points are assigned once only.
- A process has initialization code, and a "while (true)" loop.
- It has a "proctor table" described in the reference above, that by a simple, hidden goto gets the process to any rescheduling point. See here.
- A process has only one reason to be scheduled.
- A process may send on a channel, but there is no output guard.
- A process may receive on a single channel.
- A process may wait on a list of channels in an ALT. Each component may have a boolean guard to that it's easy to switch this on and off in the process. If false that component is skipped. When one component of the ALT has become activated (is that the word?), then the ALT is torn down, so that all the other entries's "first" state is nulled.
- You could start "individs" of each process, but then you would have to parameterise the channels.
- Each process has a struct of local variables which is allocated on the heap by a malloc in the initialisation part. Call this the "context". This is never freed, so it's easy to know if you have overflowed.
- ...
- A simple return from the process code gets you down to the scheduler. Therefore, no blocking calls are allowed from any subroutine level.
- When the scheduler finds no cause to schedule a channel or there is no channel waited for, there is a system fault. You probably have a deadlock.
- To avoid deadlock, use a deadlock free pattern, like knock-come from blog note 009.
- No external functions may call any function in a process file (except the scheduler).
- The process context is local to a process, and not seen elsewhere. Only parts of it are exposed to the channel (place and sizeof).
- Two processes may call a common function, since this scheduler is not preemptive. But do it seldom, and in no case let that function have any side effects. This means that it cannot alter common state (like registers or static etc.). The exception is all channel handling, ie. all scheduler functions. Of course it has system side effects, but not application side effects.
- Channel size is dynamic, but the sender and receiver must agree. So a common protocol definition header file must be made. A protocol is a collection of structs with tags and data.
- With this system communication and synchronization is the same. If you use buffering, it may become the same.
- Channel names are handled by en enum, values from 0 to n. Channels may have to be initialized. I do it in a separate function, that would init all.
- ...
- Coding the ALT is the most complex, because you may need a bitset (any primitive word size or array), used by each ALT to represent the ALT set. An ALT is "built" or "tore down". You need it so that the first that arrives on the channel, only refers to that bitset to tear down, with no knowledge of the other components.
- If you need "fair ALT", then you could bundle the ALT set in an array, and start the ALT with an index which is one more than the one just "taken". The index needs to wrap around in modulo n
- If you need processes to have priority, think twice (priority inversion etc.).
- If you have thought twice, make one ready queue for each priority.
- But maybe you would rather think of channels as the means to supply priority. Should they instead be prioritized? But do think twice on this too.
- If you do need priority, play on team with the interrupt functions. The chip designers would have thought out a scheme for you.
- Use macros to make it code better readable and hide parameters that don't need to be seen. But be aware of limitations, like Neuron C does not support #if or #elif. The synchronization points described in [5] uses labels thas absolutely should be invisible.
- ...
Sunday, January 15, 2012
Tuesday, December 27, 2011
036 - WYSIWYG semantics
Monday, December 19, 2011
035 - Channels and rendezvous vs. safety-critical systems
Moved to http://www.teigfam.net/oyvind/home/technology/035-channels-and-rendezvous-vs-safety-critical-systems on 11April2017
Saturday, December 3, 2011
034 - Output guard vs. "channel ready" channel
On the airplane home, the other day, I came upon an idea that I thought would make life easier. When I told a guy at work, he said, "oh, it's already in Linux".
I assume that you're somewhat familiar with "channels". In this respect I was raised with the occam language. (You would find Wikipedia-articles for most of the names I'll throw here. So I won't get too deep into some details.)
Here, a channel is based on CSP (later), and it is one-directional, non-buffered and blocking. It's even one-to-one. It connects tight processes to each other. It also allows threads to be equally tight. So, the first process that comes to a channel (be it sender or receiver), must be descheduled and not ever run again before the second process arrives on the channel. At that time there's a memcpy of the correct data from the sender's private context, to the receiver's matching field. It is possible to make it type safe. The message is passed across, while both sender and receiver are still. In Ada it's called a rendezvous. In Go it has no name. When the memcpy is done, usually the second on the channel just runs on, while the first is put in the ready-to-be-scheduled queue.
There is a mechanism called on ALT or a "select", where a process may wait for a number of (input) channels. A channel may be with data, without data, or timeouts. In my world (opposite to Linux select), there is exactly one cause that may trigger the SELECT. I will use capitalized "SELECT" here to cover any such idiom, to differentiate from the Linux "select". The first cause that triggers the SELECT will be stored and cause a later rescheduling, but any potential causes that "lost", will not be allowed to cause an additional triggering. Only one cause per scheduling of a process. Very different from Linux select.
Said differently: the SELECT will put all the channels in the set to "first was here". When the first "second" contender on a channel in the set arrives, all the "first" attributes are removed from the rest of the set. This is a beautiful algorithm, that I think was first implemented in microcode on the first transputer processer in 1984. Inmos in Bristol, UK, made it, and David May and Tony Hoare (the father of CSP, "Communicating Sequential Processes" process algebra) were the main architects. The transputer basically was a machine designed to run the subset of CSP that was called occam. It's 28 years ago. Ada based its concurrency model on CSP. And 26 years after occam, Google designed the Go programming language, which also has based its concurrency model on CSP, just like the same guys had done at Lucent some 10 years before with their Limbo language. Except, at that time they didn't state the roots of their "chan of protocol". And transputer designer David May now is active with a company called XMOS, and a language called XC, based on the same ideas. So, CSP-based concurrency seems to be increasingly coming.
With this scheme communication equals synchronization.
In CSP they talk about "choice". It may be deterministic or "external" or nondeterministic or "internal" (often written as [] and |~|).
The SELECT is for the teacher who assigns work to his students. He then falls to sleep (or does other things) and is awaked when the first student is finished. The student is then served, and the SELECT is entered again. The new set may include the first student, when some fair scheme is used to avoid him spam the teacher. Or the SELECT may be non-deterministic. Read in the literature, f.ex. the Promela Wiki-article (more below).
With this scheme, the teacher may say that one of the students is not allowed to deliver his result before after two hours. So, there may be timers in the SELECT set. This would also make busy polling possible, should this be needed at the application level. But the run-time scheduler NEVER needs busy-polling. Another way to say this is that a process always has a cause when it's scheduled. Just think about Java's notify and notifyall, which may schedule a process for no reason!
Also, there may be an INPUT GUARD for each channel (applied to our special student for two hours). This is usually implemented as a conditional to each member of the SELECT set. Think of the SELECT GUARD set as a bit-mask, one bit per element in the set, just like in Linux select.
Now I'm getting closer to the theme of this note: Output guard vs. "channel ready" channel.
Some times it's required to buffer a message on a channel. In occam we used to do this by inserting a single buffer process, or a couple of processes to make one composite process called an "overflow buffer", which made it possible to detect a too eager producer and associated too slow consumer - at this application level. One time I needed a buffer of a hundred buffer positions, and I just started 100 buffers. Easy! The downside was that there would be 101 memory copies, so most often a ring buffer was administered inside the first of the two processes in the composite overflow buffer process.
The alternative could be for the eager producer (it has no idea itself how eager it is) to have something called an OUTPUT GUARD available. If you want to see it, have a look at the Promela process meta language (Wikipedia). This way, both inputs and outputs may be collected in the SELECT. So, having just one channel, plus an "else", then the potential receiver, if it is able to receive, will inform through the output guard if it's ok to send. If not, the else will be taken. The SELECT with both input and output looks like the Linux select, but that one doesn't have the synchronized mechanism in the bottom.There is a code examples in [6] (here, search for bufchansched).
It's a nice mechanism. I have never had it in my world. It was not implemented on the transputer, since it was a multi-core programming language. And implementing it across a network (links) presumably was not worth it. There was another mechanism to get the same functionality. If you know what mechanism, please comment.
An output guard mechanism is good for detecting a broken line. To detected a connected line, there would have to be polling. Busy polling is most often necessary for this (assuming no hw edge interrupt). But the output guard seems not so relevant to handle the fast producer, slow consumer scenario - between internal processes. The same broken / connected scenario also would go for detecting that the other process has stopped, for some reason. Perhaps enough for a new blog note here.
So, here's the solution, to avoid the output guard, to avoid busy polling. The solution that also almost exists in Linux.
A standard channel has zero buffers. Have a look at Promela and Go. They both support buffered channels. So, why not add them to [1]? What should happen when such a channel is full? The channel send just returns a flag saying that it’s full, and the channel would not block in that situation. Observe that blocking is perfectly ok and does not impact what a system is able to do. With enough "parallel slackness" to get all the I/O going at required speed, having a process block (waiting in a non-busy way, for the second to arrive at the channel). But for a driver, close to the "asynchronous world" it's nice not to block to get rid of incoming messages. And it's nice not to send it into an asynchronous message system that may plainly overflow, crash and restart. We need a better system. We need the driver process to not block in that situation and itself handle overflows.
So, in the suggestion, after the return of the buffer full flag, the process knows this and if any incoming message arrives from the external asynchronous world, it may set a hold line, send a hold message or throw away the message - or whatever it decides to. It's up to the process.
In this state, the process will SELECT around a timeout channel and this channel that's triggered by the run-time system, that arrives when there is room in the channel. The receiver has picked out one message or all, that semantics is not so important here.
When this "channel ready" channel fires, the process can send off the last message, which may also be tagged with an overflow bit, on the channel. And it's guaranteed to succeed (unlike in Linux).
I was rather satisfied by inventing this on the plane home. I didn't like that it was already in Linux write and select. I have tried to describe some of the dissimilarities. See [2] for write, EAGAIN or EWOULDBLOCK and [3] for select (or pselect) and fd_set *writefds. It's in the context of writing to a Linux pipe.
But please, could anyone help me with describing how my solution is much "thread safer" than Linux? I need more than this:
I have more of a language, since I would do as described and reasoned above. Linux calls and Linux processes and threads are not understood by C or C++. Up to C++11 at least. And only so much understood by Linux. A C++ library for Linux needed several mutexes and semaphors to implement an ALT/SELECT in the CSP context [4]. So, are write and select usages in Linux really thread safe? I have a scheduler that is driven by the channels, and it's not preemptive. And why do Linux programmers brag that they "program single-threaded"? Is it an indication that the Linux process model is too coarse or difficult or expensive? So that they haven't learned to decompose into processes, when there is state or roles to hide away into a separate process? After object-orientation or OO, it's time for process-orientation as an additional idiom.
Should have been fun to set up a comparison table of the CSP type SELECT with channel ready channel and the similar Linux solution. Even if they are both fruits, I fear that one is apple and the other bananas?
Observe that a Linux pipe is byte-wise. You send so many bytes and then so many bytes, and they are concatenated in the pipe. There has to be a common view of how to pick out each message or token.Common usage of Linux select
This implies that you could read past a token, since a sender may have to break up a message into several chunks. There is no foldback, you cannot push anything back again. So, the receiver has to keep track of these things.
A channel is message based. A full message per chunk. Finito.
A collegue told me that the common usage of a Linux select is to remove active polling for events from remote machines from the application level, in say a http server (router). He said that he always used select to wait for events on already open sockets. One socket per bit in the select bit map."My idea" - again
Internally between threads he never had used select.
And he rarely used ip addresses internally between processes, so no select there either.
I found an interesting sentence in [5]. Here is its process-oriented specification of a buffer: If a buffer is empty it must be ready for input. If it contains some messages, then the buffer must be ready to output the next message required. It is also possible that it will accept further input, but it does not have to. (my comment: is this buffer full?) But here is the interesting sentence: "If further events are to be possible (such as a channel which can report on whether or not the channel is empty), then...". This is "my" channel! I am even more convinced now, that "my" idea was quite good!Epilogue: "The XCHAN paper"
During June and July 2012 I had the opportunity to channel this blog note into a full blown paper for the CPA-2012 (at University of Abertay Dundee, Scotland 26-29 August 2012). I have published for the WoTUG and CPA series conferences several times before, but this time it was especially exciting. See [8] and here:
XCHANs: Notes on a New Channel Type
Øyvind TEIG, Autronica Fire and Security AS, Trondheim, NorwayAbstract. This paper proposes a new channel type, XCHAN, for communicating messages between a sender and receiver. Sending on an XCHAN is asynchronous, with the sending process informed as to its success. XCHANs may be buffered, in which case a successful send means the message has got into the buffer. A successful send to an unbuffered XCHAN means the receiving process has the message. In either case, a failed send means the message has been discarded. If sending on an XCHAN fails, a built-in feedback channel (the x-channel, which has conventional channel semantics) will signal to the sender when the channel is ready for input (i.e., the next send will succeed). This x-channel may be used in a select or ALT by the sender side (only input guards are needed), so that the sender may passively wait for this notification whilst servicing other events. When the x-channel signal is taken, the sender should send as soon as possible -- but it is free to send something other than the message originally attempted (e.g. some freshly arrived data). The paper compares the use of XCHAN with the use of output guards in select/ALT statements. XCHAN usage should follow a design pattern, which is also described. Since the XCHAN never blocks, its use contributes towards deadlock- avoidance. The XCHAN offers one solution to the problem of overflow handling associated with a fast producer and slow consumer in message passing systems. The claim is that availability of XCHANs for channel based systems gives the designer and programmer another means to simplify and increase quality.
[1] - http://www.teigfam.net/oyvind/pub/pub_details.html#NewALT
"New ALT for Application Timers and Synchronisation Point Scheduling"
Øyvind Teig and Per Johan Vannebo
Communicating Process Architectures 2009 (CPA-2009)
Peter H. Welch et. al. (Eds.)
IOS Press, 2009, ISBN 978-1-60750-065-0
[2] - http://linux.die.net/man/2/write
[3] - http://linux.die.net/man/2/select
[4] - Search for "C++CSP2"
[5] - Concurrent and real-time systems. The CSP approach. Steve Schneider. Wiley, 2000. Page 210, example about buffers (7.4.1).[6] - Lecture at NTNU, Trondheim in April 2012: http://www.teigfam.net/oyvind/pub/NTNU_2012/foredrag.pdf - search for "bufchansched", since it's in Norwegian[7] - Communicating Process Architectures 2012 (CPA-2012): http://www.wotug.org/cpa2012/. Full programme: http://www.wotug.org/cpa2012/programme.shtml[8] - "XCHANs: Notes on a New Channel Type"Øyvind TeigCommunicating Process Architectures 2012.Peter H. Welch et. al.(Eds.).ISBN (later)
.
Archive
-
▼
2012
(7)
- ► 03/18 - 03/25 (1)
- ► 03/04 - 03/11 (1)
- ► 02/26 - 03/04 (1)
- ► 01/29 - 02/05 (2)
- ► 01/15 - 01/22 (1)
-
►
2011
(12)
- ► 12/25 - 01/01 (1)
- ► 12/18 - 12/25 (1)
- ► 11/27 - 12/04 (1)
- ► 09/25 - 10/02 (2)
- ► 08/07 - 08/14 (1)
- ► 07/17 - 07/24 (1)
- ► 06/26 - 07/03 (1)
- ► 06/12 - 06/19 (1)
- ► 03/06 - 03/13 (1)
- ► 02/06 - 02/13 (1)
- ► 01/09 - 01/16 (1)
-
►
2010
(8)
- ► 12/26 - 01/02 (1)
- ► 09/19 - 09/26 (1)
- ► 08/15 - 08/22 (1)
- ► 04/18 - 04/25 (1)
- ► 04/11 - 04/18 (1)
- ► 03/14 - 03/21 (1)
- ► 01/17 - 01/24 (2)
-
►
2009
(13)
- ► 07/19 - 07/26 (1)
- ► 07/12 - 07/19 (1)
- ► 06/28 - 07/05 (1)
- ► 04/05 - 04/12 (1)
- ► 03/15 - 03/22 (2)
- ► 03/01 - 03/08 (1)
- ► 02/22 - 03/01 (1)
- ► 02/08 - 02/15 (1)
- ► 02/01 - 02/08 (1)
- ► 01/18 - 01/25 (1)
- ► 01/11 - 01/18 (2)
Popular Posts
-
10May2021: Moved to https://www.teigfam.net/oyvind/home/older-blog-notes/
-
Original posting Intro and quotes Observe that in 2010 the "action" goes on at the comment and bottom level of this post! [...
-
1. From Apple Pages to iPhoto and your own paper book I have now for the second time used Apple Pages and iPhoto to make my own books. Appl...
-
Moved to http://www.teigfam.net/oyvind/home/technology/109-know-your-timers-types/ on 4Sept2015
Øyvind Teig
- aclassifier
- Trondheim, Norway
All new blogs and new home page start at
http://www.teigfam.net/oyvind/home
Overview of old blog notes here
My technology blog was at
http://oyvteig.blogspot.com
and my handicraft blog was at
http://oyvteig-2.blogspot.com
PS: just call me "Oyvind"