ACM SIGOPS European Workshop最新文献

{"title":"Goal-oriented programming, or composition using events, or threads considered harmful","authors":"R. V. Renesse","doi":"10.1145/319195.319208","DOIUrl":"https://doi.org/10.1145/319195.319208","url":null,"abstract":"Many applications, and particularly distributed applications, are about dealing with events. The code is of the form: when this message arrives do this; when this timer expires do that; when that server fails do something else; etc. Perhaps the most natural way to program this is by using interrupt handlers. Programmers have found this hard to program, and prefer loops of the form: for ever { e = await event(); handle event(e); }. But there are several problems with this approach. The handle event routine may take a long time to execute, slowing down the handling of subsequent events. Worse, handle event may invoke await event to wait, for example, for the reply of a Remote Procedure Call. To deal with this, the thread abstraction was introduced. While threads are handling events, or awaiting specific events, unrelated events can be handled by other threads. Unfortunately, anybody who has ever used threads extensively will agree that threads are error prone, hard to debug, and often non-portable. Composing packages that use different thread abstractions is usually not possible or extremely hard. The only widely popular language that supports threads well, Java, is still rarely used for serious distributed systems applications. Even there, simple applets that use threads often have bugs in them, in that they do not stop when they are off the screen, do not start up correctly when they reappear, or have race or deadlock conditions when they access shared object instances. I believe that thread fork is the goto equivalent of parallel programming. Both request a transfer to a particular entry in your program, with no indication of scope. Once you use a bunch of these in your program, any underlying logical structure is now lost, and the program becomes hard to understand and debug. Another basic problem is that available thread synchronization paradigms are either too low-level, or too coarse-grained. Low-level mechanisms like semaphores are very error-prone. Coarse-grained mechanisms like monitors do not allow for much parallelism by overspecifying the amount of synchronization required. An alternative idea is to go back to programming directly with events. Although many event management and notification systems are under development that generate, filter, and deliver events (among many examples, Corba [5] and Yeast [4]), they do not provide much help with writing a program that takes events as input. Below, I will propose a new programming technique that I call goal-oriented programming, which goes back to the roots of step-wise refinement of programs. I will show that this technique is not only easier than programming with threads, but it also provides better performance and portability. I will illustrate this by means of an example that I will work out first using threads, then using goal-oriented programming. I will conclude with a description of my experience with a transactional file system I have built this way.","PeriodicalId":241677,"journal":{"name":"ACM SIGOPS European Workshop","volume":"19 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-09-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117291475","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}