[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     [probably Sunday]
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       [probably Sunday]
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 Sunday]
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 value ...

HAVi - an Architecture for Distributed Communicating Computers for your Home AV System         [probably Sunday/Monday]
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 introduction process.

Dynamic occam 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        [probably Monday]
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        [probably Monday]
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 Multiprocessors        [probably Monday]
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 ...