Communicating Process Architectures
Communicating Process Architectures 2012, the
34th WoTUG conference on concurrent and parallel programming, will take place
at the
University of Abertay Dundee, in Dundee,
Scotland, from Sunday August 26th to Wednesday August 29th 2012.
For more information on CPA 2012, please see the
Call for Papers,
or the CPA 2012 pages.
About WoTUG
WoTUG provides a forum for the discussion and promotion of concurrency ideas,
tools and products in computer science.
It organises specialist workshops and annual conferences that address
key concurrency issues at all levels of software and hardware granularity.
WoTUG aims to progress the leading state of the art in:
-
theory (programming models, process algebra, semantics, ...);
-
practice (multicore processors and run-times, clusters, clouds, libraries, languages, verification, model checking, ...);
-
education (at school, undergraduate and postgraduate levels, ...);
-
applications (complex systems, modelling, supercomputing, embedded systems, robotics, games, e-commerce, ...);
and to stimulate discussion and ideas on the roles concurrency will play in the future:
-
for the next generation of scalable computer infrastructure (hard and soft) and application,
where scaling means the ability to ramp up functionality (stay in control as complexity increases)
as well as physical metrics (such as absolute performance and response times);
-
for system integrity (dependability, security, safety, liveness, ...);
-
for making things simple.
Of course, neither of the above sets of bullets are exclusive.
WoTUG publications
A database of papers and presentations from WoTUG conferences is here.
The Abstract below has been randomly selected from this database.
High Cohesion and Low Coupling: the Office Mapping Factor
By Øyvind Teig
This case observation describes how an embedded industrial software
architecture was “mapped” onto an office layout. It describes a particular type of program architecture that does this mapping rather well. The more a programmer
knows what to do, and so may withdraw to his office and do it, the higher the
cohesion or completeness. The less s/he has to know about what is going on in other offices, the lower the coupling or disturbance. The project, which made us aware of this, was an embedded system built on the well-known process data-flow
architecture. All interprocess communication that carried data was on synchronous, blocking channels. In this programming paradigm, it is possible for a process to refuse to “listen” on a channel while it is busy doing other things. We think that this in a way corresponds to closing the door to an office. When another process needs to communicate with such a process, it will simply be blocked (and descheduled). No queuing is done. The process, or the programmer, need not worry about holding up others. The net result seems to be good isolation of work and easier implementation. The isolation also enables faster pinpointing of where an error may be and, hence, in fixing the error in one place only. Even before the product was shipped, it was possible to keep the system with close to zero known errors. The paradigm described here has become a valuable tool in our toolbox. However, when this paradigm is used, one must also pay attention should complexity start to grow beyond expectations, as it may be a sign of too high cohesion or too little coupling.
Complete record...
|
