用于图形数据流语言的本地化条件处理构造

ACM-SE 28 Pub Date : 1990-04-01 DOI:10.1145/98949.99015
D. Langan
{"title":"用于图形数据流语言的本地化条件处理构造","authors":"D. Langan","doi":"10.1145/98949.99015","DOIUrl":null,"url":null,"abstract":"This paper gives a brief description of dataflow programming and of the condition handling constructs used in existing dataflow languages. It is argued that existing mechanisms arc deficient both in terms of flexibility and performance. A construct that provides for increased flexibility and improved performance is presented. The construct described here is called a supervisor and has three component parts called (a) the input acceptance lest, (b) the condition handler and (c) the output acceptance test. The basic dataflow model is expanded to include condition arcs and tokens. The construct presented here is a part of a more comprehensive scheme for condition handling in dataflow models [Langan 88]. AN INTRODUCTION TO DATAFLOW The increased use of computers, the decrease in (heir cost, and the application of computers to more complex problems, has led to languages and architectures designed to take advantage of increased processing power. Languages have evolved that allow the programmer to identify computations that can be executed in asynchronous fashion (e.g., Ada and Modula-2). Such parallel processing languages allow for a clear statement of algorithms that require parallel execution. The languages mentioned above all have one aspect in common; they are control flow based languages which assume multiple loci of execution. Another approach for the description of parallel computations is dataflow. The essential characteristics of basic datallow arc: (1) A dataflow graph is collection of nodes, each providing a side effect free function, connected by directed arcs. The arcs arc the data paths along which the data tokens flow from node to node. (2) A node executes (or fires), consuming its input tokens, only if the input it requires is available and if adequate space is available for anv output tokens.____________________________ Permission lo copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct com­ mercial advantage, live ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or lo republish, requires a fee and/or specific per­ mission. © 1990 ACM 0-89791-356-6/90/0400/0118 $1.50 (3) All communication including input values, output values and synchronization signals is via tokens. Figure 1: A Dataflow Graph Figure 1 shows a dataflow graph called G dial computes (a+b)*(a-b). The compulations for + and can be performed as soon as tokens holding values for a and b, appear on the input arcs to the nodes labeled N1 and N2. The + and may be executed in parallel. Dataflow languages differ from oilier parallel processing languages in that their execution is data driven as opposed lo being driven by control flow. Many descriptions of dataflow have appeared in the literature of the past twenty years. [Karp 1966, Dennis 1975, Landry 1981, Veen 1986], define different dataflow models. These models differ with respect to the atomic operations available, the use of arcs, and the rules concerning the firing of nodes. As a result, a \"standard\" dataflow model docs not exist; however, most of the models proposed are basically similar. These models assume dial nodes represent deterministic sideeffect free compulations. An excellent overview of both proposed models and architectures may be found in [Arvind 1986, Srini 1986, Veen 1986]. A condition is an event that is deemed noteworthy. An event, at the hardware level, might be the existence of a designated slate after a given instruction (c.g., overflow after multiplication) or it might refer to an attempt to make an invalid memory reference (e.g., range error on an array reference). At the programming level, an event might refer to a particular set of values for a specified set of variables during execution. Conditions may include slates predefined by the system, language support environment, or the user of the programming language. The existence of a noteworthy event may be independent of its detection. The act of checking to determine if a condition has occurred or that the condition exists, is referred to as condition detection. The signaling of the fact that a condition exists is called posting the condition. A condition handler is a collection of responses that are taken if a condition is detected. A condition handler may include the resumption, termination or modification of the execution environment of the associated code. The major problems with conditions concern detection, flow of control, association of condition handlers with code, and the transfer of condition notification through environments. EXISTING DATAFLOW LANGUAGES Proposals for condition handling in dataflow differ substantially. Three major efforts at creating a new high level dataflow language have been VAL [Ackerman 1979], Id [Arvind 1978] and Lucid [Wadge 1985]. In VAL the problem of handling conditions is dealt with by extending each token type to include condition values (c.g., OVERFLOW [Integer] or ZERO_DIVIDE [Real]). The semantics of each operator is extended to include the various condition values that might be received (e.g., P O S I T I V E _ O V E R F L O W + X = POSITIVE_OVERFLOW if 0 ^ X, X = P O S I T I V E . O V E R F L O W o r X = POSITIVE.UNDERFLOW, otherwise UNKNOWN). Plouffc [Plouffc 1980] proposes a mechanism for exception handling and recovery in applicative systems and demonstrates his proposal in terms of Id. Plouffc’s mechanism differs from the VAL approach in that he creates a type specifically for conditions. This \"condition\" type permits more flexibility for condition handling. For example, the user could define new types of conditions, whereas with VAL the user is limited to predefined condition values. Plouffc’s error type allows for a \"composite\" type of condition through the concatenation of error notifications. In Lucid conditions are also treated as a separate data type, but the various operators provided have an extended semantics to allow for the use of condition tokens. Unlike the two approaches described above, the condition tokens do not carry with them any information that would convey the original cause of the condition and hence condition handling is made more difficult. The three linguistic mechanisms proposed for the textual dataflow languages VAL, Id [PloulTc 1980) and Lucid demonstrate certain similarities; in particular, all three do the following: (1) extend the basic operators to include the facility to produce an output even if a condition should occur, (2) extend functionality to deal with","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"45 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":"{\"title\":\"A localized condition handling construct for a graphical dataflow language\",\"authors\":\"D. Langan\",\"doi\":\"10.1145/98949.99015\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"This paper gives a brief description of dataflow programming and of the condition handling constructs used in existing dataflow languages. It is argued that existing mechanisms arc deficient both in terms of flexibility and performance. A construct that provides for increased flexibility and improved performance is presented. The construct described here is called a supervisor and has three component parts called (a) the input acceptance lest, (b) the condition handler and (c) the output acceptance test. The basic dataflow model is expanded to include condition arcs and tokens. The construct presented here is a part of a more comprehensive scheme for condition handling in dataflow models [Langan 88]. AN INTRODUCTION TO DATAFLOW The increased use of computers, the decrease in (heir cost, and the application of computers to more complex problems, has led to languages and architectures designed to take advantage of increased processing power. Languages have evolved that allow the programmer to identify computations that can be executed in asynchronous fashion (e.g., Ada and Modula-2). Such parallel processing languages allow for a clear statement of algorithms that require parallel execution. The languages mentioned above all have one aspect in common; they are control flow based languages which assume multiple loci of execution. Another approach for the description of parallel computations is dataflow. The essential characteristics of basic datallow arc: (1) A dataflow graph is collection of nodes, each providing a side effect free function, connected by directed arcs. The arcs arc the data paths along which the data tokens flow from node to node. (2) A node executes (or fires), consuming its input tokens, only if the input it requires is available and if adequate space is available for anv output tokens.____________________________ Permission lo copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct com­ mercial advantage, live ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or lo republish, requires a fee and/or specific per­ mission. © 1990 ACM 0-89791-356-6/90/0400/0118 $1.50 (3) All communication including input values, output values and synchronization signals is via tokens. Figure 1: A Dataflow Graph Figure 1 shows a dataflow graph called G dial computes (a+b)*(a-b). The compulations for + and can be performed as soon as tokens holding values for a and b, appear on the input arcs to the nodes labeled N1 and N2. The + and may be executed in parallel. Dataflow languages differ from oilier parallel processing languages in that their execution is data driven as opposed lo being driven by control flow. Many descriptions of dataflow have appeared in the literature of the past twenty years. [Karp 1966, Dennis 1975, Landry 1981, Veen 1986], define different dataflow models. These models differ with respect to the atomic operations available, the use of arcs, and the rules concerning the firing of nodes. As a result, a \\\"standard\\\" dataflow model docs not exist; however, most of the models proposed are basically similar. These models assume dial nodes represent deterministic sideeffect free compulations. An excellent overview of both proposed models and architectures may be found in [Arvind 1986, Srini 1986, Veen 1986]. A condition is an event that is deemed noteworthy. An event, at the hardware level, might be the existence of a designated slate after a given instruction (c.g., overflow after multiplication) or it might refer to an attempt to make an invalid memory reference (e.g., range error on an array reference). At the programming level, an event might refer to a particular set of values for a specified set of variables during execution. Conditions may include slates predefined by the system, language support environment, or the user of the programming language. The existence of a noteworthy event may be independent of its detection. The act of checking to determine if a condition has occurred or that the condition exists, is referred to as condition detection. The signaling of the fact that a condition exists is called posting the condition. A condition handler is a collection of responses that are taken if a condition is detected. A condition handler may include the resumption, termination or modification of the execution environment of the associated code. The major problems with conditions concern detection, flow of control, association of condition handlers with code, and the transfer of condition notification through environments. EXISTING DATAFLOW LANGUAGES Proposals for condition handling in dataflow differ substantially. Three major efforts at creating a new high level dataflow language have been VAL [Ackerman 1979], Id [Arvind 1978] and Lucid [Wadge 1985]. In VAL the problem of handling conditions is dealt with by extending each token type to include condition values (c.g., OVERFLOW [Integer] or ZERO_DIVIDE [Real]). The semantics of each operator is extended to include the various condition values that might be received (e.g., P O S I T I V E _ O V E R F L O W + X = POSITIVE_OVERFLOW if 0 ^ X, X = P O S I T I V E . O V E R F L O W o r X = POSITIVE.UNDERFLOW, otherwise UNKNOWN). Plouffc [Plouffc 1980] proposes a mechanism for exception handling and recovery in applicative systems and demonstrates his proposal in terms of Id. Plouffc’s mechanism differs from the VAL approach in that he creates a type specifically for conditions. This \\\"condition\\\" type permits more flexibility for condition handling. For example, the user could define new types of conditions, whereas with VAL the user is limited to predefined condition values. Plouffc’s error type allows for a \\\"composite\\\" type of condition through the concatenation of error notifications. In Lucid conditions are also treated as a separate data type, but the various operators provided have an extended semantics to allow for the use of condition tokens. Unlike the two approaches described above, the condition tokens do not carry with them any information that would convey the original cause of the condition and hence condition handling is made more difficult. The three linguistic mechanisms proposed for the textual dataflow languages VAL, Id [PloulTc 1980) and Lucid demonstrate certain similarities; in particular, all three do the following: (1) extend the basic operators to include the facility to produce an output even if a condition should occur, (2) extend functionality to deal with\",\"PeriodicalId\":409883,\"journal\":{\"name\":\"ACM-SE 28\",\"volume\":\"45 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1990-04-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"0\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"ACM-SE 28\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/98949.99015\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"ACM-SE 28","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/98949.99015","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0

摘要

在VAL中,处理条件的问题是通过扩展每个令牌类型来包含条件值来处理的(例如,OVERFLOW [Integer]或ZERO_DIVIDE [Real])。每个操作符的语义被扩展为包括可能接收到的各种条件值(例如,POSITIVE_OVERFLOW + X = POSITIVE_OVERFLOW if 0 ^ X, X = POSITIVE)。O O O O O O O O O O O O O O X =正。UNDERFLOW(否则未知)。Plouffc [Plouffc 1980]提出了一种在应用系统中处理和恢复异常的机制,并从Id的角度论证了他的建议。Plouffc的机制不同于VAL方法,因为他专门为条件创建了一个类型。这种“条件”类型允许更灵活地处理条件。例如,用户可以定义新类型的条件,而使用VAL时,用户只能使用预定义的条件值。Plouffc的错误类型允许通过错误通知的连接实现“复合”类型的条件。在Lucid中,条件也被视为单独的数据类型,但是提供的各种操作符具有扩展的语义,以允许使用条件令牌。与上面描述的两种方法不同,条件令牌不携带任何可以传达条件的原始原因的信息,因此使条件处理变得更加困难。为文本数据流语言VAL、Id [PloulTc 1980]和Lucid提出的三种语言机制表现出一定的相似性;具体来说,这三种方法都做了以下工作:(1)扩展基本运算符,使其包括即使出现条件也能产生输出的功能;(2)扩展处理的功能
本文章由计算机程序翻译,如有差异,请以英文原文为准。
A localized condition handling construct for a graphical dataflow language
This paper gives a brief description of dataflow programming and of the condition handling constructs used in existing dataflow languages. It is argued that existing mechanisms arc deficient both in terms of flexibility and performance. A construct that provides for increased flexibility and improved performance is presented. The construct described here is called a supervisor and has three component parts called (a) the input acceptance lest, (b) the condition handler and (c) the output acceptance test. The basic dataflow model is expanded to include condition arcs and tokens. The construct presented here is a part of a more comprehensive scheme for condition handling in dataflow models [Langan 88]. AN INTRODUCTION TO DATAFLOW The increased use of computers, the decrease in (heir cost, and the application of computers to more complex problems, has led to languages and architectures designed to take advantage of increased processing power. Languages have evolved that allow the programmer to identify computations that can be executed in asynchronous fashion (e.g., Ada and Modula-2). Such parallel processing languages allow for a clear statement of algorithms that require parallel execution. The languages mentioned above all have one aspect in common; they are control flow based languages which assume multiple loci of execution. Another approach for the description of parallel computations is dataflow. The essential characteristics of basic datallow arc: (1) A dataflow graph is collection of nodes, each providing a side effect free function, connected by directed arcs. The arcs arc the data paths along which the data tokens flow from node to node. (2) A node executes (or fires), consuming its input tokens, only if the input it requires is available and if adequate space is available for anv output tokens.____________________________ Permission lo copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct com­ mercial advantage, live ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or lo republish, requires a fee and/or specific per­ mission. © 1990 ACM 0-89791-356-6/90/0400/0118 $1.50 (3) All communication including input values, output values and synchronization signals is via tokens. Figure 1: A Dataflow Graph Figure 1 shows a dataflow graph called G dial computes (a+b)*(a-b). The compulations for + and can be performed as soon as tokens holding values for a and b, appear on the input arcs to the nodes labeled N1 and N2. The + and may be executed in parallel. Dataflow languages differ from oilier parallel processing languages in that their execution is data driven as opposed lo being driven by control flow. Many descriptions of dataflow have appeared in the literature of the past twenty years. [Karp 1966, Dennis 1975, Landry 1981, Veen 1986], define different dataflow models. These models differ with respect to the atomic operations available, the use of arcs, and the rules concerning the firing of nodes. As a result, a "standard" dataflow model docs not exist; however, most of the models proposed are basically similar. These models assume dial nodes represent deterministic sideeffect free compulations. An excellent overview of both proposed models and architectures may be found in [Arvind 1986, Srini 1986, Veen 1986]. A condition is an event that is deemed noteworthy. An event, at the hardware level, might be the existence of a designated slate after a given instruction (c.g., overflow after multiplication) or it might refer to an attempt to make an invalid memory reference (e.g., range error on an array reference). At the programming level, an event might refer to a particular set of values for a specified set of variables during execution. Conditions may include slates predefined by the system, language support environment, or the user of the programming language. The existence of a noteworthy event may be independent of its detection. The act of checking to determine if a condition has occurred or that the condition exists, is referred to as condition detection. The signaling of the fact that a condition exists is called posting the condition. A condition handler is a collection of responses that are taken if a condition is detected. A condition handler may include the resumption, termination or modification of the execution environment of the associated code. The major problems with conditions concern detection, flow of control, association of condition handlers with code, and the transfer of condition notification through environments. EXISTING DATAFLOW LANGUAGES Proposals for condition handling in dataflow differ substantially. Three major efforts at creating a new high level dataflow language have been VAL [Ackerman 1979], Id [Arvind 1978] and Lucid [Wadge 1985]. In VAL the problem of handling conditions is dealt with by extending each token type to include condition values (c.g., OVERFLOW [Integer] or ZERO_DIVIDE [Real]). The semantics of each operator is extended to include the various condition values that might be received (e.g., P O S I T I V E _ O V E R F L O W + X = POSITIVE_OVERFLOW if 0 ^ X, X = P O S I T I V E . O V E R F L O W o r X = POSITIVE.UNDERFLOW, otherwise UNKNOWN). Plouffc [Plouffc 1980] proposes a mechanism for exception handling and recovery in applicative systems and demonstrates his proposal in terms of Id. Plouffc’s mechanism differs from the VAL approach in that he creates a type specifically for conditions. This "condition" type permits more flexibility for condition handling. For example, the user could define new types of conditions, whereas with VAL the user is limited to predefined condition values. Plouffc’s error type allows for a "composite" type of condition through the concatenation of error notifications. In Lucid conditions are also treated as a separate data type, but the various operators provided have an extended semantics to allow for the use of condition tokens. Unlike the two approaches described above, the condition tokens do not carry with them any information that would convey the original cause of the condition and hence condition handling is made more difficult. The three linguistic mechanisms proposed for the textual dataflow languages VAL, Id [PloulTc 1980) and Lucid demonstrate certain similarities; in particular, all three do the following: (1) extend the basic operators to include the facility to produce an output even if a condition should occur, (2) extend functionality to deal with
求助全文
通过发布文献求助,成功后即可免费获取论文全文。 去求助
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:604180095
Book学术官方微信