Newsgroups: comp.sys.transputer From: Richard Beton Subject: Re: client/server (was Post Mortem) Organization: Roke Manor Research Limited Date: Fri, 20 Feb 1998 17:38:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34EDBFB2.574511DD@roke.co.uk.no.spam.thankyou> NewsMan wrote: > Alec Cawley wrote > > >I agree in principle, but CSP != occam, at least if you use the > >expansion of the algorithm. I have no problems with separate tasks which > >communicate almost entirely by sending messages [1]. What I find occam > >lacks is the concept of a "daemon server" and the facilities for > >"client" threads to communicate with "servers" which don't know the > >number or type of their clients. > > > > > I this this is an important point. It seems that part of the reason for > pushing a rigid program design methodology was to enable the > proving of deadlock avoidance. Laudable though that is, for a > system in the real world programmers were wanting to develop > client-server models as Alec illustrates. Sadly in those days, the client-server paradigm was something you had to code up the hard way using pairs of occam channels. Future occam programmers (cough!) will have the benefit of the client server model being burnt deeply into the langauge - well, occam3 programmers that is! Anyone using the Kent compiler (see http://www.hensa.ac.uk/parallel) on a Unix machine already has access to prototypical forms of the client/server model. The occam3 client/server approach has some interesting features: * a server need not know how many clients it has; it transacts with them sequentially * a server can contain code which itself transacts as a client to sub-servers * cyclic dependencies can be eliminated by analysis, i.e. servers should not be clients of subservers who are ultimately their own clients. If cyclic dependencies are eliminated, deadlock *cannot* occur between any clients and servers. There have been some exciting theoretical developments on this issue over the last few years. * when a server accepts a transaction, it is effectively doing an ALT (the ALT can also include other ordinary channels and timers). The wacky feature is that the server alternation takes unit time. It does not matter how many clients there are. Wow! Much better than hand-coded pairs of occam2 channels, where the alternation time grows linearly with the number of clients. * a server terminates when all of its clients have terminated, without needing to be told so to do. Avoiding deadlock is an ever increasing problem. I now do lots of Java programming and I'm aware of some of the pitfalls, thanks to wokshops organised by WoTUG (details on Hensa website). Java encourages multi-threaded programming, and so it should. But perhaps there's a tendency to play down the danger of deadlock. Or alternatively, where deadlock might occur, advocate instead a re-write in sequential form (which can still deadlock, ironically, should there be a resource contention). In fact, you *cannot* tell that a multi-threaded system is free from deadlock just by testing it. Therefore, if you haven't proven it deadlock free by analysis, the chances are it could deadlock sometime in the future. Perhaps occam is going to give its biggest benefit as an analysis tool for multi-threaded systems coded in other languages (notably Java). Therefore, it makes sense to keep supporting the theoretical, analytical and language work that goes on at Oxford, Canterbury, and other Universities. ... On which topic, have you seen the Call for Participants for the WoTUG21 Conference in April? (shameless plug!) Rick -- Richard Beton BSc CPhys MInstP Roke Manor Research Limited --------- Standard Disclaimer about my own views etc etc -------- --------- My mail client accepts rich text (HTML) mail -------- Welsh Highland Railway: http://www.whr.co.uk/WHR/WHR.html