Computer Science Conference Presentations, Computer Science Posters and Proceedings 10-10-2010 Concurrency by modularity: design patterns, a case in point Hridesh Rajan [email protected] Steven M. Kautz Iowa State University, [email protected] Wayne Rowcliffe Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_conf Part of the Software Engineering Commons Recommended Citation Rajan, Hridesh; Kautz, Steven M.; and Rowcliffe, Wayne, "Concurrency by modularity: design patterns, a case in point" (2010). Computer Science Conference Presentations, Posters and Proceedings. 39. http://lib.dr.iastate.edu/cs_conf/39 This Conference Proceeding is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Conference Presentations, Posters and Proceedings by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Concurrency by modularity: design patterns, a case in point Abstract General purpose object-oriented programs typically aren't embarrassingly parallel. For these applications, finding enough concurrency remains a challenge in program design. To address this challenge, in the Panini project we are looking at reconciling concurrent program design goals with modular program design goals. The ainm idea is that if programmers improve the modularity of their programs they should get concurrency for free. In this work we describe one of our directions to reconcile these two goals by enhancing Gang-of- Four (GOF) object-oriented design patterns. GOF patterns are commonly used to improve the modularity of object-oriented software. These patterns describe strategies to decouple components in design space and specify how these components should interact. Our hypothesis is that if these patterns are enhanced to also decouple components in execution space applying them will concomitantly improve the design and potentially available concurrency in software systems. To evaluate our hypothesis we have studied all 23 GOF patterns. For 18 patterns out of 23, our hypothesis has held true. Another interesting preliminary result reported here is that for 17 out of these 18 studied patterns, concurrency and synchronization concerns were completely encapsulated in our concurrent design pattern framework. Disciplines Computer Sciences | Software Engineering Comments This article is published as Rajan, Hridesh, Steven M. Kautz, and Wayne Rowcliffe. "Concurrency by modularity: Design patterns, a case in point." In ACM Sigplan Notices, vol. 45, no. 10, pp. 790-805. ACM, 2010. doi: 10.1145/1932682.1869523. Posted with permission. Rights © ACM, 2010. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in ACM Sigplan Notices, vol. 45, no. 10, pp. 790-805. ACM, 2010. https://doi.org/10.1145/1932682.1869523 This conference proceeding is available at Iowa State University Digital Repository: http://lib.dr.iastate.edu/cs_conf/39 Concurrency by Modularity: Design Patterns, a Case in Point Hridesh Rajan Steven M. Kautz Wayne Rowcliffe Dept. of Computer Science Iowa State University 226 Atanasoff Hall, Ames, IA, 50010, USA {hridesh,smkautz,wrowclif}@iastate.edu Abstract Keywords Modularity, concurrency, ease of program de- General purpose object-oriented programs typically aren’t sign, design patterns, synergistic decoupling embarrassingly parallel. For these applications, finding enough concurrency remains a challenge in program de- 1. Introduction sign. To address this challenge, in the Pa¯nini¯ project we A direct result of recent trends in hardware design towards are looking at reconciling concurrent program design goals multicore CPUs with hundreds of cores is that the need with modular program design goals. The main idea is that for scalability of today’s general-purpose programs can no if programmers improve the modularity of their programs longer be simply fulfilled by faster CPUs. Rather, these pro- they should get concurrency for free. In this work we de- grams must now be designed to take advantage of the inher- scribe one of our directions to reconcile these two goals by ent concurrency in the underlying computational model. enhancing Gang-of-Four (GOF) object-oriented design pat- terns. GOF patterns are commonly used to improve the mod- 1.1 The Problems and their Importance ularity of object-oriented software. These patterns describe Scalability of general-purpose programs faces two major strategies to decouple components in design space and spec- hurdles. A first and well-known hurdle is that writing cor- ify how these components should interact. Our hypothesis is rect and efficient concurrent programs has remained a chal- that if these patterns are enhanced to also decouple compo- lenge [2, 22, 24, 32]. A second and less explored hurdle is nents in execution space applying them will concomitantly that unlike in scientific applications, in general-purpose pro- improve the design and potentially available concurrency in grams potential concurrency isn’t always obvious. software systems. To evaluate our hypothesis we have stud- We believe that both these hurdles are in part due to a ied all 23 GOF patterns. For 18 patterns out of 23, our hy- significant shortcoming of the current concurrent language pothesis has held true. Another interesting preliminary result features or perhaps the design discipline that they promote. reported here is that for 17 out of these 18 studied patterns, These features treat modular program design and concurrent concurrency and synchronization concerns were completely program design as two separate and orthogonal goals. As a encapsulated in our concurrent design pattern framework. result, concurrent program design as a goal is often tackled at a level of abstraction lower than modular program design. Categories and Subject Descriptors D.2.10 [Software Synchronization defects arise when developers work at low Engineering]: Design; D.1.5 [Programming Techniques]: abstraction levels and are not aware of the behavior at a Object-Oriented Programming; D.2.2 [Design Tools and higher level of abstraction [23]. This unawareness also limits Techniques]: Modules and interfaces, Object-oriented design potentially available concurrency in resulting programs. methods; D.2.3 [Coding Tools and Techniques]: Object- To illustrate consider a picture viewer. The overall re- Oriented Programming; D.3.3 [Programming Languages]: quirement for this program is to display the input picture Language Constructs and Features raw, hereafter referred to as the display concern. To enhance General Terms Design, Human Factors, Languages the appearance of pictures this program is also required to apply such transformations as red-eye reduction, sharpening, etc, to raw pictures, henceforth referred to as the processing concern. The listing in Figure 1 shows snippets from a sim- Permission to make digital or hard copies of all or part of this work for personal or ple implementation of this picture viewer. classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation This listing shows a GUI-related class Display that on the first page. To copy otherwise, to republish, to post on servers or to redistribute is responsible for drawing borders, captions and displaying to lists, requires prior specific permission and/or a fee. Onward! 2010, October 17–21, 2010, Reno/Tahoe, Nevada, USA. pictures. The key method of the picture viewer is show, Copyright c 2010 ACM 978-1-4503-0236-4/10/10. $5.00. which given a raw picture processes it, draws a border and The class Processor now implements the processing 1 class Display { 2 Picture pic = null; concern using the Template Method design pattern [12]. 3 void show(Picture raw) { It provides a new template method process for its 4 Picture tmp = crop(raw); 5 tmp = sharpen(raw, tmp); client [12]. This allows independent evolution of var- 6 pic = redeye(raw, tmp); ious parts of the processing concern’s implementation, 7 displayBorders(); 8 displayCaption(); e.g. a new algorithm for red eye reduction could be 9 displayPicture(pic); added without extensively modifying the clients. Concrete 10 } 11 Picture redeye(Picture raw, Picture pic){ processing algorithms are implemented in the subclass 12 //Identify eyes in raw, make a copy of pic, BasicProcessor. The class Display creates and uses 13 //replace eye areas in copy with a gradient of blue. 14 return copy; } an instance of BasicProcessor on lines 4 and 5 respec- 15 Picture sharpen(Picture raw, Picture pic){ tively but remains independent of its implementation. 16 //Identify areas to sharpen in raw, make a copy 17 //of pic, increases contrast of selected areas in copy. 18 return copy; } 1.1.2 Improving Concurrency of Picture Viewer 19 Picture crop(Picture raw){ 20 // Find focus area, make a copy of raw, crop copy. On another day we may want to enhance the responsiveness 21 return copy; } of the picture viewer. An approach to do that could be to 22 //Elided code for displaying border, caption, and pic. 23 } render borders, captions, etc, concurrently with picture pro- cessing, which may take a long time to finish. This would Figure 1: A Picture Viewer and its two Tangled Concerns prevent such common nuisances as the “frozen user inter- face”. Starting