Communicating Process Architectures - 2000
Sunday 8:00 - 10:00pm (Keynes LT2/SR7) and Monday 8:00 - 10:00pm
[This takes place during the Sunday and Monday evening SIGs (8:00 -
10:00pm). The arrangements are very informal. The talks listed here
are provisional - some may be withdrawn and new ones added at any time.
The ideas floated represent recently completed work, work-in-progress,
kite flying and outright provocation. The plan is for there to be
a maximum of interaction between presenters and audience - a workshop
athmosphere. There are no written proceedings to go with this programme
- it's too new.
Past workshops have sparked off many intersting ventures - including
SPoC, KRoC, CTJ, JCSP and the hardware/priority extensions to CSP ...]
Towards a Successor to occam
Ian R. East (Oxford Brookes University, UK)
Abstract: occam offers
features and attributes that made it unique among programming languages.
After a brief summary of these, possible additional features will be discussed,
including the automatic avoidance of deadlock, recursion, source code
modularity, and exception response. It is hoped to provoke a debate about
the future of programming communicating process architecture, and lay
some foundations for a new programming language.
Processes vs. Objects - Towards a Better
Component Based Language ... or
CSP: More object oriented than Object Oriented?
Tom Locke (Computing Laboratory, University of Kent)
Abstract: Experience with OO programming has shown that
the paradigm fails to deliver its promised 'divide and conquer' utopia
of componentised design and implementation. This talk is concerned with
the design of a CSP based programming language that tries to do a better
job. We shall investiagte serious problems with OO and how a CSP model
can solve them. The need for a new language will then be demonstrated,
by showing that there are important features (some obvious, some subtle)
that OO provides but occam does not. A language design that does combine
these strengths will then be discussed.
better.state vs. better.occam - 2000 vs.
1988? [probably Sunday]
Oyvind Teig (Navia Maritime AS, div. Autronica, Norway)
Abstract: What do graphical state-machine tools offer?
Can their functionality in any way be compared with that of "old" occam
2? We will try to contrast this with a critical comment by Bernard Sufrin,
OUCL, about such graphical tools.
Is the baroque style of system architecture
so fashionable? [probably
Stephen Maudsley (Esgem Limited, UK)
Abstract: Over the past few months I've been reviewing
a number of new communications technologies. When the question "how
do I integrate technology XXX into my system" get the response "we
have a protocol stack for that sir". The ancillary question "and
what about the synchronisation model" seems to get one of two replies
(a) a blank stare or (b) thats an operating system issue ...
Baroque style - wonderfully tall twirly bits that aren't of any practical
HAVi - an Architecture for Distributed Communicating
Computers for your Home AV System
Stephen Maudsley (Esgem Limited, UK)
Abstract: The largest consumer electronics manufacturers
on the planet have formed the HAVi trade organization to develop an architecture
to be used as a common applications platform for networked audio/video
appliances. Here is an overview of the architecture and a review of the
Processes [probably Monday]
Fred Barnes (Computing Laboratory, University of Kent)
Abstract: The dynamic occam processes extension to the
KRoC/Linux system allows a pre-compiled occam process to be dynamically
loaded into an active process network. These dynamic processes attach
themselves through channels to the rest of the process network.
Since dynamic processes reside in separate workspaces, they can be suspended,
written to disk, read from disk, and resumed. This provides a level
of process management not previously available in occam. In a networked
environment, these processes can be migrated to other nodes - providing
mobile processes, load-balancing ...
A GUI/Graphics Library for occam
Paul White (Computing Laboratory, University of Kent)
Abstract: Modern Graphical User Interface (GUI) packages
have changed the face of computing in recent years, allowing even the
most uncultured of computer users to acheive their goals with moderate
ease. The GRaphical occam ProjEct (GRoPE) brings occam
into the world of GUIs and graphics applications. The library implementation
takes advantage of the (non-)blocking system calls recently introduced
into the PC/Linux KRoC (see the talk by Fred Barnes in the main conference)
to wait passively for GUI events. GUI events become high level channel
communications. Standard graphics widgets, layout managers and drawing
areas become occam processes that communicate with application specific
processes in the normal way. This work revises the earlier mocca
project and is built using the public domain GTK toolkit.
Continuous CSP? Ridiculous! ... or
What has to break when CSP meets the real
continuous world ... or
Can we use the same language for software,
digital hardware and analogue hardware?
Adrian Lawrence (Computing Services, Oxford University)
SMP-MESH: Fast Multithreading on Shared Memory
Joseph Cordina (Computer Science, University of Malta, Malta)
Abstract: MESH is a fast user-level thread scheduler
with inter-thread and network communication facilities developed at CERN.
The original MESH only takes advantage of uniprocessor hosts. SMP-MESH
is an adaptation of MESH that runs on shared memory multi-processor platforms
while maintaining low latency scheduling. Using a shared run queue protected
by spin locks, multiple user-level threads may run concurrently, while
also communicating concurrently. Load balancing through thread migration
is automatic. The API is unchanged from the original MESH, allowing a
seamless and automatic transition from uniprocessor machines on to SMP
machines while automatically taking advantage of the extra processors.
Results show good speedups, but also indicate bottlenecks caused by contention
for shared data structures at very fine thread granularity. Further experiments
are being carried out on alternative designs to reduce contention and
improve cache exploitation in the context of fine grain thread scheduling.
and more ...