New 31Aug2015, updated 17Nov2015

This page is in group Technology and is a note presenting two presentations at an international conference’s fringe sessions.

CPA 2015

Communicating Process Architectures 2015 (CPA 2015) was held at the School of Computing, University of Kent, Canterbury UK (see http://www.wotug.org/cpa2015/). There were two nights with fringe presentations and I had one each night. These abstracts and presentations are also on the CPA page. They were as usual edited by the editors of the proceeding, but not the presentations.

Both were presented as “Øyvind TEIG, Autronica Fire and Security AS, Trondheim, Norway”

Not that blocking!

Abstract. Communicating to fellow programmers that the concept of “blocking” in process-oriented design is perfectly acceptable, while using a word with basically negative connotations, is difficult. The bare need to do it often means that misunderstanding this concept is harmful. The first contender on a “blocking channel” has also correctly been said (by several people) to “wait” on the channel. A better correspondence between the negative meaning and the semantics is when “blocking” describes serious side effects on the temporal properties of other concurrent components. This is the correctly feared blocking. This fringe presentation will explore this further and invite discussion.

The official abstract is here and my presentation is here. It is based on my blog note Not so blocking after all.

Not that concurrent!

Abstract. Concurrency is, in the literature, often used as a noun with a range of strengths: there is more or less concurrency; it is more or less limited; it may even be seen described as complete. In trying to discuss multi-threaded programming with programmers who state that they program single-threaded, it is important to communicate that they may program less concurrently, but probably not as non-concurrently as they believe. What are the factors that increase concurrency and which factors are orthogonal to the degree of concurrency? Does a Go language goroutine increase it and is a C++ object orthogonal? Will the CSP paradigm generally enable increased concurrency? Is the CSP paradigm of communication-with-synchronisation itself orthogonal to the degree of concurrency? It is also important to understand the term parallel slackness: does it introduce or enable more concurrency? And what about atomicity? This fringe presentation aims to raise more questions that it is able to answer. However, some lines of reasoning are suggested. Finally: is it at all meaningful to raise the awareness of concurrent as an adjective?

The official abstract is here and my presentation is here. It is based on my blog note How much concurrency?