Little Book of Semaphores: Threading Learning Tool

The Little Book of Semaphores

Threading Learning Tool

Requirements Specifications

Glenn Pirozzi

Dr. Bi

09/17/2010

Submitted in partial fulfillment

Of the requirements of

CMPS 490 – Computer Projects Little Book of Semaphores: Threading Learning Tool

Abstract

Synchronization is a huge problem that must be addressed in any software application that uses threading, communications, or any parallel connections or computing. Most do not see the practical side to the synchronization problems; they see solutions but never implementations of said solutions. Threading is an easy way to show examples of parallel computing and the power of synchronization and its uses of semaphores. If a person would like to learn the application of synchronization through a programming language they understand; they will be able to once this project is completed. This project will incorporate python examples of the use of semaphores and synchronization from the book The Little Book of Semaphores into an understandable version of Java that will utilize threads to test said examples. Through this rewriting of the python examples; there will be a better understanding for current Computer

Science Majors and any subset Majors on the real applications of synchronization solutions.

2 Little Book of Semaphores: Threading Learning Tool

Table of Contents

Table of Contents Abstract...... 1

Table of Contents...... 2

Chapter 1 - Introduction...... 3

Chapter 2 –System Model...... 4

Chapter 3 - Functional requirements...... 5

Chapter 4 - User interface specification...... 7

Chapter 5 - Non-functional requirements...... 8

Chapter 6 - System evolution...... 9

Glossary...... 11

Index...... 12

Chapter 1 - Introduction

One thing many students in the field of Computing Science have trouble with is the subject of Threading and Synchronization. This problem includes the ideas of synchronization and protection through the use of Semaphores. To understand their use you must have an understanding of parallel computing and grasp the idea of multiple processes accessing the same data and or resources. My objective for my application is to enable a greater understanding of

Semaphore use through threading. My hopes are for a very easy to use application that is lightweight with a well documented and organized program files that any programmer and or user can understand the uses of Semaphores.

All students need help from time to time, my application will do just that. It will help students who need a supplement or a visual to see just how threading and Semaphores work.

Semaphores are one of the more advanced topics in the field of Computing Science, to have a reliable source that can help a student better understand Semaphores and its use in threads could set some students minds at ease; even help other students achieve a higher understanding of the topic. Even students who don't necessarily need to use this application as a learning tool in the sense of seeing how Semaphores work can use this application to test out different common and uncommon cases of Semaphore solutions. The application will come with a finite number of

Semaphore solutions, all of which have cases with and without semaphores to demonstrate the difference between a program being protected and unprotected. If a student wants to see just what the effects an unprotected program will have, that student can with my application. A student may also write their own cases, which I will even include in the manual what

4 Little Book of Semaphores: Threading Learning Tool specifications it needs, as well as specifications on writing other "drivers" to be used with the application. If an example is not there for a student to use, a student may add this into the application, using the guidelines I create and just add the file to a Java package.

This application has and will take some effort to make. It has been built with the idea of expansion of its "drivers" and the addition of extra cases into the development process. Because of this, any extra features can be added at any point without as much worry to time constraint.

This program can be finished on time, with all features that are planned to be included because of the previously stated. The only part of the project I can foresee giving me any type of problem is the idea of a dynamically growing application. As it is right now, the application must be manually edited if new cases are added or new drivers are added. The plan is to implement classes and methods that will handled the construction of some of the menus by looking at a list or the packages itself to build the application. This will make it easier for other users to add in new features.

Chapter 2 –System Model

This application; as was described in chapter 1 is a very lightweight application with the ability for user created content in the form of drivers and cases. It should be noted that the application has been built with this in mind and includes documentation on how to achieve the integration of user created content. In the application the user will interact with Java classes called drivers. The drivers are the classes that run the application and specify everything from what the user sees to how the user will interact with the cases. After the drivers take the user input; although it should be noted that this is not user input as in raw data from the user through keyboard or other input, but through user selections of buttons and drop down menus, they select

5 Little Book of Semaphores: Threading Learning Tool the appropriate case. These cases then run their processes, handling all semaphore usage and all test threading. The cases also handle output through the manipulation of a passed object through which the driver will ultimately display.

This structure, from the user to the driver to the cases insures the lightweight design of the application is fulfilled. This design structure also ensures that, even though most users of the application will be involved in looking at and creating code for the application, the three tier hierarchy of the application insures a separation of user from cases. The drivers act as a middle man handling what the user sees and how the user interacts with the cases creating a safe and stable environment. Because of this stable and easy to use environment, this application can be used for a variety of uses, not only those of threading, although that will not be its focused function, but a function that a user will have to create. That is the most powerful part of this application is the fact that there is no limit to this application, if a user wants to write a new driver, they can, and implement it into the application with minimal effort.

Chapter 3 - Functional requirements

The main focus of the application is to give the user a learning environment to test cases of semaphore and thread usage in java. The application will include pre-written drivers including the main driver which launches separate drivers. Right now there are only two "sub drivers" planned which are the single driver and double driver. These are drivers which as their names suggest do a single and double output respectively. These two drivers will take the users selection of a case and execute that case. The case will then provide output back to the sub driver which will then display the output area to the user.

If you, being the user, want to include your own sub driver to demonstrate a different way of looking at an example, or even possible to do some function outside of the realm of the programs intended education of thread and semaphore usage; this can be done. The only requirements will be your ability with the Java programming language and the usage of the documentation and integration with the main driver. Although the application will dynamically build how the main driver looks either based off of an easily editable text file, or by looking into the driver package, making it completely possible to add in a new driver with little to no effort on integration into the application.

Other than the drivers being included in the program, are a plethora of classes called cases. These cases, of which on the subject of user created content, will work similarly to drivers in the respect to integration with the application. They are executed by the sub drivers and hold most if not all of the testing code. There will be included in the final application around 50 cases, all translated from the book "The Little Book of Semaphores" by Allen B. Downey. The code they are translated from is Python into Java. This will give new users a better understanding if they are to look at the cases, as Java is a more relevant programming language to most students and new users. It will also give users a basis from which to start testing from. They will have 50 cases to test and see the difference between protected and un-protected threads, as well as a greater understanding of what they themselves could create and run. Although a great focus of the development of this application is the cases and the translation, a large focus will also be placed on the potential of user created content and the ability of a user to learn from this tool and be able significantly understand the uses of semaphores and threads.

Chapter 4 - User interface specification

As described above the application takes on a three tier structure. It takes a three tier stricter in both design and implementation. It is designed with the idea that a user starts the main driver in which they can select a sub driver. With that sub driver they can then select a case or cases to run with multiple options for output. It is also a three tier in implementation in that the user, one tier, interacts with the drivers, the second tier, which ultimately executes the cases. The look and feel of each tier can be a bit different, and sometimes the same.

The user will from the outside on a pure: only using this application with what is written and what is provided, will interact and see only the drivers and sub drivers. The main driver is a small window, rectangle in shape. The rectangle of the main driver has a higher height than its width. It includes buttons, all buttons from the top going down in one column are the sub driver buttons and will on user press, execute the sub drivers. The last button in the column is the exit button, of which will exit both the main driver and any sub drivers currently opened.

The sub drivers are all slightly similar to each other. The first, the single driver is a larger rectangular window, similar in shape structure to the main driver. It includes a top centered white output window, with a drop down selection under the output window and a run button next to the drop down window to the right of it and under the output window. The user will select what they want to test from the list of cases, then they will hit run to see the results of that particular case.

The second driver, the double driver, is very close to the single driver, except that it includes two output windows and under each output window a drop down selection. Each drop down selection corresponds to the window it is under. The run button is slightly off set from the single driver due to the addition of a second drop down selection. It should also be noted that a save selection

8 Little Book of Semaphores: Threading Learning Tool may be included as well as other "tool" features. These will be included in the final application, although they may not all work, they will however at least give the user an explanation of what there functions will be once they are written with future updates.

What the user sees as output varies depending on which case is selected. Each case is unique and will have slightly to massively varying degrees of output, all shown in the output window of a sub driver. Because of this an explanation of what the user will see cannot be explained. However it can be explained that when the user hits the run button, they will see the word run displayed in the output window before the case is executed. This output of run is handled by the sub driver as to not have to worry about the problems of synchronization and protection.

Chapter 5 - Non-functional requirements The only thing a user will need to run the applications and cases is a computer with the

JRE 2 or Java Runtime Environment 2 as I will be developing these applications with Java SE 6 and I cannot guarantee that anything I use from Java SE 6 will be compatible with previous

JRE's. I will however recommend that a user attempt to test these solutions on a computer with a processor capable of hyper threading or at least a multiprocessor computer as I will be testing threading solutions with semaphores for synchronization and without a multiprocessor, users may not be able to see the negative effects of non synchronization. If a user has a processor with hyper threading and or multiple processors the user will have a better chance of witnessing the problems and benefits of non synchronization and synchronization.

Every case used in this program has its own response time, which is even affected by the hardware used. This application will be tested on many different platforms, including windows

9 Little Book of Semaphores: Threading Learning Tool and Linux (Ubuntu v10.4). It will also be tested on a netbook with a 1.83 GHz Intel atom processor with 1GB of DDR 3 memory; it will also be tested on a desktop with a 2.66 GHz Intel core i7 processor with 6GB of DDR 3 memory. I will be able to confirm that this application will run on most if not all hardware that falls between these two specified hardware setups.

All the code used in the application will be uniform in how it is setup. Each case uses the same constructor parameters making it easy to write other cases and implement them. Each sub driver may be written in any manner due to the fact that the main driver only executes the sub driver, the sub driver does not receive any parameters from the main driver. The documentation of the program will have detailed instructions on how to add new sub drivers and cases. It will explain the needed requirements of integration into the application. The entire application will have uniform comments explaining uses and choices for code and will also explain integration practices for the application. The goal is to create a user friendly code atmosphere where changes and new features may be added without damaging the overall application.

Chapter 6 - System evolution The only assumption that has been made for the application is the fact that each case will receive only an object, to be more precise a JText area. If a user created driver does not take this into account, all previously written cases will have to be changed for the new parameters that a sub driver sends to be accepted. Any new user created cases can accept any parameters they so choose, although this will be discouraged as they cannot easily be officially included into future releases of application. The other assumption made is that as of now, no official sub drivers will be written with the idea that a user will be able to input any data other than a selection from a list or the press of buttons. Users will not be able to submit any text input or any files directly from the sub drivers.

As stated throughout the paper, the application is being written to dynamically build both the main driver and the list of cases. This way all user created sub drivers and cases can be integrated into the application. This system design also makes it easy for future updates as any new features can be written into an old sub driver without worry of incompatibility with user created content; new content can also be added without worry in the form of new sub drivers and new cases. The dynamic structure of the application ensures that future releases and support are possible, as well as personal user maintenance and additions. These are all welcomed as long as the user respects the documentation that will be provided with the application.

Glossary Driver - Parts of the application that run all the features and execute other drivers and cases

Main driver - Driver that starts all the sub drivers

Sub driver - Drivers that include outputs and features used for running cases

Case - Coded examples of semaphore and thread usage that are able to execute

Semaphore- The classic method for restricting access to shared resources (e.g. storage) in a multi- processing environment. (http://dictionary.reference.com/browse/semaphore)

case, 6, 8, 9, 10 main driver, 6, 7, 8, 10, 11 drivers, 5, 6, 7, 8, 10, 11, 12 Semaphore, 4,