Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-26T23:41:44Z

Washao: /* Actions Performed in the Shopper Pattern */

= Shopper Pattern =

== Preface ==
E-commerce has been increasingly popular these past few years and people who want a good deal are certainly taking full advantage of online shopping. Regardless of where online shoppers go, there is one consistent factor – the shopping cart. Shoppers shop online by adding items to the shopping cart and at the end can compare prices, remove items and make adjustments. There are certainly some variations of the shopping cart but the main functionalities are there as a “standard”. This “standard” leads to shopper pattern.

=== Shopper Pattern Defined ===
Shopper pattern is the inner workings of online shopping – it helps in collecting items from providers (brand names, different products etc.) and presents them to the user. It takes in users' inputs (desire to purchase by adding to cart) and at the end display the contents the user desires. It helps in facilitating the final purchase and then communicates with the providers about the purchase. This pattern is basically a middleman – shoppers and providers have no knowledge of each other – shopper buys the product and the shopper pattern takes care of communicating to the provider. Of course in the E-commerce world there are fierce competitions – many competitors’ shopping carts might have more/better functionalities than others (mini shopping carts (Barnes & Noble), dynamic item availability (Amazon)) but they all branch from the basic shopper pattern.

== Actors in the Pattern ==
The shopper pattern has three main actors: the consumer, the provider, and the cart.

=== Consumer ===
The consumer requests an item or multiple items to be placed in the cart.

=== Provider ===
The provider is the entity or person that holds the items that consumers wish to attain. The provider may not necessarily have what the consumer requests of it.

=== Cart ===
The cart is the middleman between the consumer and provider. Its job is to maintain the requests as agreed upon between the consumer and provider.

=== Item ===
This is the object that the consumer desires, the provider possesses, and the cart tracks. The requirement for an item is that it has to be an asset that can be conveyed from the provider to the consumer.

== When to use a Shopper Pattern ==
* When a consumer could possibly want more than one different item from a provider.
* When a consumer could possibly want multiple of the same item from a provider.
* When a consumer may wish to take a break in shopping then return to shopping.
* When a consumer may wish to conduct payment at a later time.

== Actions Performed in the Shopper Pattern ==
[[Image:Actor.jpg]]

There are multiple actions performed by the consumer and provider on the cart. They are as follows:

=== Consumer ===
==== View cart ====
The consumer wishes to view his/her collection of items amassed in the cart. This is a very important action because the provider can also influence what is in the cart, namely the quantity of items due to availability.

==== Add to cart ====
The consumer requests that a certain quantity of an item be added to the cart. The cart queries the provider as to whether the resources are available to furnish this request. If so, the quantity of items is added to the cart. If the full quantity cannot be added to the cart, the maximum quantity allowable is added (this includes when none are available).

==== Update cart ====
The consumer changes a quantity of items in the cart. The cart does a query to the provider exactly like when an item is added to the cart.

==== Remove from cart ====
The consumer requests that all of a certain type of item be removed from the cart. The provider is notified of this action, but does not provide input.

=== Shopper pattern ===
==== Check avail. ====
The shopper pattern checks the availability of items desired by the consumer by calling the provider.

=== Provider ===
==== Update inven. ====
The provider can update the current inventory so the consumer can be informed of any sudden changes when updating the cart.

== Exercising the Shopper Pattern ==
''Put a chart and stuff here that shows how it all works.''

== Other Examples of Shopper Pattern ==
The shopper pattern does not have to be used for an e-commerce shopping cart. There shopper pattern can be generalized as a collection of objects being provided by a provider and being requested by a consumer. Some other examples of possible shopper pattern are:
* A library - A library patron (consumer) requesting books or other materials (items) from the library (provider). The patron can make a list of materials needed to be picked up or checked out. In this example no money exchanges hands, payment in this case is just a promise to return the materials.

= Resources =
* [http://www.welie.com/patterns/showPattern.php?patternID=shopping-cart Shopping Cart - Interactive Design Pattern Library]
* [http://ui-patterns.com/pattern/ShoppingCart Shopping Cart - UI-patterns.com]
* [http://www.surl.org/usabilitynews/92/shoppingcart.asp Usability News - Naidu]
* [http://www.guuui.com/browse.php?cid=152 Shopping Carts - GUUUI]

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-26T23:41:04Z

Washao: /* Actions Performed in the Shopper Pattern */

= Shopper Pattern =

== Preface ==
E-commerce has been increasingly popular these past few years and people who want a good deal are certainly taking full advantage of online shopping. Regardless of where online shoppers go, there is one consistent factor – the shopping cart. Shoppers shop online by adding items to the shopping cart and at the end can compare prices, remove items and make adjustments. There are certainly some variations of the shopping cart but the main functionalities are there as a “standard”. This “standard” leads to shopper pattern.

=== Shopper Pattern Defined ===
Shopper pattern is the inner workings of online shopping – it helps in collecting items from providers (brand names, different products etc.) and presents them to the user. It takes in users' inputs (desire to purchase by adding to cart) and at the end display the contents the user desires. It helps in facilitating the final purchase and then communicates with the providers about the purchase. This pattern is basically a middleman – shoppers and providers have no knowledge of each other – shopper buys the product and the shopper pattern takes care of communicating to the provider. Of course in the E-commerce world there are fierce competitions – many competitors’ shopping carts might have more/better functionalities than others (mini shopping carts (Barnes & Noble), dynamic item availability (Amazon)) but they all branch from the basic shopper pattern.

== Actors in the Pattern ==
The shopper pattern has three main actors: the consumer, the provider, and the cart.

=== Consumer ===
The consumer requests an item or multiple items to be placed in the cart.

=== Provider ===
The provider is the entity or person that holds the items that consumers wish to attain. The provider may not necessarily have what the consumer requests of it.

=== Cart ===
The cart is the middleman between the consumer and provider. Its job is to maintain the requests as agreed upon between the consumer and provider.

=== Item ===
This is the object that the consumer desires, the provider possesses, and the cart tracks. The requirement for an item is that it has to be an asset that can be conveyed from the provider to the consumer.

== When to use a Shopper Pattern ==
* When a consumer could possibly want more than one different item from a provider.
* When a consumer could possibly want multiple of the same item from a provider.
* When a consumer may wish to take a break in shopping then return to shopping.
* When a consumer may wish to conduct payment at a later time.

== Actions Performed in the Shopper Pattern ==
[[Image:Actor.jpg]]

There are multiple actions performed by the consumer and provider on the cart. They are as follows:

=== Consumer ===
==== View cart ====
The consumer wishes to view his/her collection of items amassed in the cart. This is a very important action because the provider can also influence what is in the cart, namely the quantity of items due to availability.

==== Add to cart ====
The consumer requests that a certain quantity of an item be added to the cart. The cart queries the provider as to whether the resources are available to furnish this request. If so, the quantity of items is added to the cart. If the full quantity cannot be added to the cart, the maximum quantity allowable is added (this includes when none are available).

==== Update cart ====
The consumer changes a quantity of items in the cart. The cart does a query to the provider exactly like when an item is added to the cart.

==== Remove from cart ====
The consumer requests that all of a certain type of item be removed from the cart. The provider is notified of this action, but does not provide input.

=== Shopper pattern ===
==== Check avail. ====
The shopper pattern checks the availability of items desired by the consumer by calling the provider.

==== Update inven. ====
The provider can update the current inventory so the consumer can be informed of any sudden changes when updating the cart.

== Exercising the Shopper Pattern ==
''Put a chart and stuff here that shows how it all works.''

== Other Examples of Shopper Pattern ==
The shopper pattern does not have to be used for an e-commerce shopping cart. There shopper pattern can be generalized as a collection of objects being provided by a provider and being requested by a consumer. Some other examples of possible shopper pattern are:
* A library - A library patron (consumer) requesting books or other materials (items) from the library (provider). The patron can make a list of materials needed to be picked up or checked out. In this example no money exchanges hands, payment in this case is just a promise to return the materials.

= Resources =
* [http://www.welie.com/patterns/showPattern.php?patternID=shopping-cart Shopping Cart - Interactive Design Pattern Library]
* [http://ui-patterns.com/pattern/ShoppingCart Shopping Cart - UI-patterns.com]
* [http://www.surl.org/usabilitynews/92/shoppingcart.asp Usability News - Naidu]
* [http://www.guuui.com/browse.php?cid=152 Shopping Carts - GUUUI]

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-26T23:39:22Z

Washao: /* Actions Performed in the Shopper Pattern */

= Shopper Pattern =

== Preface ==
E-commerce has been increasingly popular these past few years and people who want a good deal are certainly taking full advantage of online shopping. Regardless of where online shoppers go, there is one consistent factor – the shopping cart. Shoppers shop online by adding items to the shopping cart and at the end can compare prices, remove items and make adjustments. There are certainly some variations of the shopping cart but the main functionalities are there as a “standard”. This “standard” leads to shopper pattern.

=== Shopper Pattern Defined ===
Shopper pattern is the inner workings of online shopping – it helps in collecting items from providers (brand names, different products etc.) and presents them to the user. It takes in users' inputs (desire to purchase by adding to cart) and at the end display the contents the user desires. It helps in facilitating the final purchase and then communicates with the providers about the purchase. This pattern is basically a middleman – shoppers and providers have no knowledge of each other – shopper buys the product and the shopper pattern takes care of communicating to the provider. Of course in the E-commerce world there are fierce competitions – many competitors’ shopping carts might have more/better functionalities than others (mini shopping carts (Barnes & Noble), dynamic item availability (Amazon)) but they all branch from the basic shopper pattern.

== Actors in the Pattern ==
The shopper pattern has three main actors: the consumer, the provider, and the cart.

=== Consumer ===
The consumer requests an item or multiple items to be placed in the cart.

=== Provider ===
The provider is the entity or person that holds the items that consumers wish to attain. The provider may not necessarily have what the consumer requests of it.

=== Cart ===
The cart is the middleman between the consumer and provider. Its job is to maintain the requests as agreed upon between the consumer and provider.

=== Item ===
This is the object that the consumer desires, the provider possesses, and the cart tracks. The requirement for an item is that it has to be an asset that can be conveyed from the provider to the consumer.

== When to use a Shopper Pattern ==
* When a consumer could possibly want more than one different item from a provider.
* When a consumer could possibly want multiple of the same item from a provider.
* When a consumer may wish to take a break in shopping then return to shopping.
* When a consumer may wish to conduct payment at a later time.

== Actions Performed in the Shopper Pattern ==
[[Image:Actor.jpg]]

There are multiple actions performed by the consumer and provider on the cart. They are as follows:

=== View cart ===
The consumer wishes to view his/her collection of items amassed in the cart. This is a very important action because the provider can also influence what is in the cart, namely the quantity of items due to availability.

=== Add to cart ===
The consumer requests that a certain quantity of an item be added to the cart. The cart queries the provider as to whether the resources are available to furnish this request. If so, the quantity of items is added to the cart. If the full quantity cannot be added to the cart, the maximum quantity allowable is added (this includes when none are available).

=== Update cart ===
The consumer changes a quantity of items in the cart. The cart does a query to the provider exactly like when an item is added to the cart.

=== Remove from cart ===
The consumer requests that all of a certain type of item be removed from the cart. The provider is notified of this action, but does not provide input.

=== Check avail. ===
The shopper pattern checks the availability of items desired by the consumer by calling the provider.

=== Update inven. ===
The provider can update the current inventory so the consumer can be informed of any sudden changes when updating the cart.

== Exercising the Shopper Pattern ==
''Put a chart and stuff here that shows how it all works.''

== Other Examples of Shopper Pattern ==
The shopper pattern does not have to be used for an e-commerce shopping cart. There shopper pattern can be generalized as a collection of objects being provided by a provider and being requested by a consumer. Some other examples of possible shopper pattern are:
* A library - A library patron (consumer) requesting books or other materials (items) from the library (provider). The patron can make a list of materials needed to be picked up or checked out. In this example no money exchanges hands, payment in this case is just a promise to return the materials.

= Resources =
* [http://www.welie.com/patterns/showPattern.php?patternID=shopping-cart Shopping Cart - Interactive Design Pattern Library]
* [http://ui-patterns.com/pattern/ShoppingCart Shopping Cart - UI-patterns.com]
* [http://www.surl.org/usabilitynews/92/shoppingcart.asp Usability News - Naidu]
* [http://www.guuui.com/browse.php?cid=152 Shopping Carts - GUUUI]

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-26T23:38:32Z

Washao: /* Actions Performed in the Shopper Pattern */

= Shopper Pattern =

== Preface ==
E-commerce has been increasingly popular these past few years and people who want a good deal are certainly taking full advantage of online shopping. Regardless of where online shoppers go, there is one consistent factor – the shopping cart. Shoppers shop online by adding items to the shopping cart and at the end can compare prices, remove items and make adjustments. There are certainly some variations of the shopping cart but the main functionalities are there as a “standard”. This “standard” leads to shopper pattern.

=== Shopper Pattern Defined ===
Shopper pattern is the inner workings of online shopping – it helps in collecting items from providers (brand names, different products etc.) and presents them to the user. It takes in users' inputs (desire to purchase by adding to cart) and at the end display the contents the user desires. It helps in facilitating the final purchase and then communicates with the providers about the purchase. This pattern is basically a middleman – shoppers and providers have no knowledge of each other – shopper buys the product and the shopper pattern takes care of communicating to the provider. Of course in the E-commerce world there are fierce competitions – many competitors’ shopping carts might have more/better functionalities than others (mini shopping carts (Barnes & Noble), dynamic item availability (Amazon)) but they all branch from the basic shopper pattern.

== Actors in the Pattern ==
The shopper pattern has three main actors: the consumer, the provider, and the cart.

=== Consumer ===
The consumer requests an item or multiple items to be placed in the cart.

=== Provider ===
The provider is the entity or person that holds the items that consumers wish to attain. The provider may not necessarily have what the consumer requests of it.

=== Cart ===
The cart is the middleman between the consumer and provider. Its job is to maintain the requests as agreed upon between the consumer and provider.

=== Item ===
This is the object that the consumer desires, the provider possesses, and the cart tracks. The requirement for an item is that it has to be an asset that can be conveyed from the provider to the consumer.

== When to use a Shopper Pattern ==
* When a consumer could possibly want more than one different item from a provider.
* When a consumer could possibly want multiple of the same item from a provider.
* When a consumer may wish to take a break in shopping then return to shopping.
* When a consumer may wish to conduct payment at a later time.

== Actions Performed in the Shopper Pattern ==
[[Image:Actor.jpg]]

There are multiple actions performed by the consumer and provider on the cart. They are as follows:

=== View Cart ===
The consumer wishes to view his/her collection of items amassed in the cart. This is a very important action because the provider can also influence what is in the cart, namely the quantity of items due to availability.

=== Add to Cart ===
The consumer requests that a certain quantity of an item be added to the cart. The cart queries the provider as to whether the resources are available to furnish this request. If so, the quantity of items is added to the cart. If the full quantity cannot be added to the cart, the maximum quantity allowable is added (this includes when none are available).

=== Update Cart ===
The consumer changes a quantity of items in the cart. The cart does a query to the provider exactly like when an item is added to the cart.

=== Remove from Cart ===
The consumer requests that all of a certain type of item be removed from the cart. The provider is notified of this action, but does not provide input.

=== Check avail. ===
The shopper pattern checks the availability of items desired by the consumer by calling the provider.

=== Update inven. ===
The provider can update the current inventory so the consumer can be informed of any sudden changes when updating the cart.

== Exercising the Shopper Pattern ==
''Put a chart and stuff here that shows how it all works.''

== Other Examples of Shopper Pattern ==
The shopper pattern does not have to be used for an e-commerce shopping cart. There shopper pattern can be generalized as a collection of objects being provided by a provider and being requested by a consumer. Some other examples of possible shopper pattern are:
* A library - A library patron (consumer) requesting books or other materials (items) from the library (provider). The patron can make a list of materials needed to be picked up or checked out. In this example no money exchanges hands, payment in this case is just a promise to return the materials.

= Resources =
* [http://www.welie.com/patterns/showPattern.php?patternID=shopping-cart Shopping Cart - Interactive Design Pattern Library]
* [http://ui-patterns.com/pattern/ShoppingCart Shopping Cart - UI-patterns.com]
* [http://www.surl.org/usabilitynews/92/shoppingcart.asp Usability News - Naidu]
* [http://www.guuui.com/browse.php?cid=152 Shopping Carts - GUUUI]

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-26T23:29:13Z

Washao: /* Actions Performed in the Shopper Pattern */

= Shopper Pattern =

== Preface ==
E-commerce has been increasingly popular these past few years and people who want a good deal are certainly taking full advantage of online shopping. Regardless of where online shoppers go, there is one consistent factor – the shopping cart. Shoppers shop online by adding items to the shopping cart and at the end can compare prices, remove items and make adjustments. There are certainly some variations of the shopping cart but the main functionalities are there as a “standard”. This “standard” leads to shopper pattern.

=== Shopper Pattern Defined ===
Shopper pattern is the inner workings of online shopping – it helps in collecting items from providers (brand names, different products etc.) and presents them to the user. It takes in users' inputs (desire to purchase by adding to cart) and at the end display the contents the user desires. It helps in facilitating the final purchase and then communicates with the providers about the purchase. This pattern is basically a middleman – shoppers and providers have no knowledge of each other – shopper buys the product and the shopper pattern takes care of communicating to the provider. Of course in the E-commerce world there are fierce competitions – many competitors’ shopping carts might have more/better functionalities than others (mini shopping carts (Barnes & Noble), dynamic item availability (Amazon)) but they all branch from the basic shopper pattern.

== Actors in the Pattern ==
The shopper pattern has three main actors: the consumer, the provider, and the cart.

=== Consumer ===
The consumer requests an item or multiple items to be placed in the cart.

=== Provider ===
The provider is the entity or person that holds the items that consumers wish to attain. The provider may not necessarily have what the consumer requests of it.

=== Cart ===
The cart is the middleman between the consumer and provider. Its job is to maintain the requests as agreed upon between the consumer and provider.

=== Item ===
This is the object that the consumer desires, the provider possesses, and the cart tracks. The requirement for an item is that it has to be an asset that can be conveyed from the provider to the consumer.

== When to use a Shopper Pattern ==
* When a consumer could possibly want more than one different item from a provider.
* When a consumer could possibly want multiple of the same item from a provider.
* When a consumer may wish to take a break in shopping then return to shopping.
* When a consumer may wish to conduct payment at a later time.

== Actions Performed in the Shopper Pattern ==
[[Image:Actor.jpg]]

There are multiple actions performed by the consumer and provider on the cart. They are as follows:

=== View Cart ===
The consumer wishes to view his/her collection of items amassed in the cart. This is a very important action because the provider can also influence what is in the cart, namely the quantity of items due to availability.

=== Add to Cart ===
The consumer requests that a certain quantity of an item be added to the cart. The cart queries the provider as to whether the resources are available to furnish this request. If so, the quantity of items is added to the cart. If the full quantity cannot be added to the cart, the maximum quantity allowable is added (this includes when none are available).

=== Update Cart ===
The consumer changes a quantity of items in the cart. The cart does a query to the provider exactly like when an item is added to the cart.

=== Remove from Cart ===
The consumer requests that all of a certain type of item be removed from the cart. The provider is notified of this action, but does not provide input.

== Exercising the Shopper Pattern ==
''Put a chart and stuff here that shows how it all works.''

== Other Examples of Shopper Pattern ==
The shopper pattern does not have to be used for an e-commerce shopping cart. There shopper pattern can be generalized as a collection of objects being provided by a provider and being requested by a consumer. Some other examples of possible shopper pattern are:
* A library - A library patron (consumer) requesting books or other materials (items) from the library (provider). The patron can make a list of materials needed to be picked up or checked out. In this example no money exchanges hands, payment in this case is just a promise to return the materials.

= Resources =
* [http://www.welie.com/patterns/showPattern.php?patternID=shopping-cart Shopping Cart - Interactive Design Pattern Library]
* [http://ui-patterns.com/pattern/ShoppingCart Shopping Cart - UI-patterns.com]
* [http://www.surl.org/usabilitynews/92/shoppingcart.asp Usability News - Naidu]
* [http://www.guuui.com/browse.php?cid=152 Shopping Carts - GUUUI]

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-26T23:28:36Z

Washao: /* Actors in the Pattern */

= Shopper Pattern =

== Preface ==
E-commerce has been increasingly popular these past few years and people who want a good deal are certainly taking full advantage of online shopping. Regardless of where online shoppers go, there is one consistent factor – the shopping cart. Shoppers shop online by adding items to the shopping cart and at the end can compare prices, remove items and make adjustments. There are certainly some variations of the shopping cart but the main functionalities are there as a “standard”. This “standard” leads to shopper pattern.

=== Shopper Pattern Defined ===
Shopper pattern is the inner workings of online shopping – it helps in collecting items from providers (brand names, different products etc.) and presents them to the user. It takes in users' inputs (desire to purchase by adding to cart) and at the end display the contents the user desires. It helps in facilitating the final purchase and then communicates with the providers about the purchase. This pattern is basically a middleman – shoppers and providers have no knowledge of each other – shopper buys the product and the shopper pattern takes care of communicating to the provider. Of course in the E-commerce world there are fierce competitions – many competitors’ shopping carts might have more/better functionalities than others (mini shopping carts (Barnes & Noble), dynamic item availability (Amazon)) but they all branch from the basic shopper pattern.

== Actors in the Pattern ==
The shopper pattern has three main actors: the consumer, the provider, and the cart.

=== Consumer ===
The consumer requests an item or multiple items to be placed in the cart.

=== Provider ===
The provider is the entity or person that holds the items that consumers wish to attain. The provider may not necessarily have what the consumer requests of it.

=== Cart ===
The cart is the middleman between the consumer and provider. Its job is to maintain the requests as agreed upon between the consumer and provider.

=== Item ===
This is the object that the consumer desires, the provider possesses, and the cart tracks. The requirement for an item is that it has to be an asset that can be conveyed from the provider to the consumer.

== When to use a Shopper Pattern ==
* When a consumer could possibly want more than one different item from a provider.
* When a consumer could possibly want multiple of the same item from a provider.
* When a consumer may wish to take a break in shopping then return to shopping.
* When a consumer may wish to conduct payment at a later time.

== Actions Performed in the Shopper Pattern ==
There are multiple actions performed by the consumer and provider on the cart. They are as follows:

=== View Cart ===
The consumer wishes to view his/her collection of items amassed in the cart. This is a very important action because the provider can also influence what is in the cart, namely the quantity of items due to availability.

=== Add to Cart ===
The consumer requests that a certain quantity of an item be added to the cart. The cart queries the provider as to whether the resources are available to furnish this request. If so, the quantity of items is added to the cart. If the full quantity cannot be added to the cart, the maximum quantity allowable is added (this includes when none are available).

=== Update Cart ===
The consumer changes a quantity of items in the cart. The cart does a query to the provider exactly like when an item is added to the cart.

=== Remove from Cart ===
The consumer requests that all of a certain type of item be removed from the cart. The provider is notified of this action, but does not provide input.

== Exercising the Shopper Pattern ==
''Put a chart and stuff here that shows how it all works.''

== Other Examples of Shopper Pattern ==
The shopper pattern does not have to be used for an e-commerce shopping cart. There shopper pattern can be generalized as a collection of objects being provided by a provider and being requested by a consumer. Some other examples of possible shopper pattern are:
* A library - A library patron (consumer) requesting books or other materials (items) from the library (provider). The patron can make a list of materials needed to be picked up or checked out. In this example no money exchanges hands, payment in this case is just a promise to return the materials.

= Resources =
* [http://www.welie.com/patterns/showPattern.php?patternID=shopping-cart Shopping Cart - Interactive Design Pattern Library]
* [http://ui-patterns.com/pattern/ShoppingCart Shopping Cart - UI-patterns.com]
* [http://www.surl.org/usabilitynews/92/shoppingcart.asp Usability News - Naidu]
* [http://www.guuui.com/browse.php?cid=152 Shopping Carts - GUUUI]

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-26T23:28:11Z

Washao: /* Actors in the Pattern */

= Shopper Pattern =

== Preface ==
E-commerce has been increasingly popular these past few years and people who want a good deal are certainly taking full advantage of online shopping. Regardless of where online shoppers go, there is one consistent factor – the shopping cart. Shoppers shop online by adding items to the shopping cart and at the end can compare prices, remove items and make adjustments. There are certainly some variations of the shopping cart but the main functionalities are there as a “standard”. This “standard” leads to shopper pattern.

=== Shopper Pattern Defined ===
Shopper pattern is the inner workings of online shopping – it helps in collecting items from providers (brand names, different products etc.) and presents them to the user. It takes in users' inputs (desire to purchase by adding to cart) and at the end display the contents the user desires. It helps in facilitating the final purchase and then communicates with the providers about the purchase. This pattern is basically a middleman – shoppers and providers have no knowledge of each other – shopper buys the product and the shopper pattern takes care of communicating to the provider. Of course in the E-commerce world there are fierce competitions – many competitors’ shopping carts might have more/better functionalities than others (mini shopping carts (Barnes & Noble), dynamic item availability (Amazon)) but they all branch from the basic shopper pattern.

== Actors in the Pattern ==
The shopper pattern has three main actors: the consumer, the provider, and the cart.

=== Consumer ===
The consumer requests an item or multiple items to be placed in the cart.

=== Provider ===
The provider is the entity or person that holds the items that consumers wish to attain. The provider may not necessarily have what the consumer requests of it.

=== Cart ===
The cart is the middleman between the consumer and provider. Its job is to maintain the requests as agreed upon between the consumer and provider.

=== Item ===
This is the object that the consumer desires, the provider possesses, and the cart tracks. The requirement for an item is that it has to be an asset that can be conveyed from the provider to the consumer.

[[Image:Actor.jpg]]

== When to use a Shopper Pattern ==
* When a consumer could possibly want more than one different item from a provider.
* When a consumer could possibly want multiple of the same item from a provider.
* When a consumer may wish to take a break in shopping then return to shopping.
* When a consumer may wish to conduct payment at a later time.

== Actions Performed in the Shopper Pattern ==
There are multiple actions performed by the consumer and provider on the cart. They are as follows:

=== View Cart ===
The consumer wishes to view his/her collection of items amassed in the cart. This is a very important action because the provider can also influence what is in the cart, namely the quantity of items due to availability.

=== Add to Cart ===
The consumer requests that a certain quantity of an item be added to the cart. The cart queries the provider as to whether the resources are available to furnish this request. If so, the quantity of items is added to the cart. If the full quantity cannot be added to the cart, the maximum quantity allowable is added (this includes when none are available).

=== Update Cart ===
The consumer changes a quantity of items in the cart. The cart does a query to the provider exactly like when an item is added to the cart.

=== Remove from Cart ===
The consumer requests that all of a certain type of item be removed from the cart. The provider is notified of this action, but does not provide input.

== Exercising the Shopper Pattern ==
''Put a chart and stuff here that shows how it all works.''

== Other Examples of Shopper Pattern ==
The shopper pattern does not have to be used for an e-commerce shopping cart. There shopper pattern can be generalized as a collection of objects being provided by a provider and being requested by a consumer. Some other examples of possible shopper pattern are:
* A library - A library patron (consumer) requesting books or other materials (items) from the library (provider). The patron can make a list of materials needed to be picked up or checked out. In this example no money exchanges hands, payment in this case is just a promise to return the materials.

= Resources =
* [http://www.welie.com/patterns/showPattern.php?patternID=shopping-cart Shopping Cart - Interactive Design Pattern Library]
* [http://ui-patterns.com/pattern/ShoppingCart Shopping Cart - UI-patterns.com]
* [http://www.surl.org/usabilitynews/92/shoppingcart.asp Usability News - Naidu]
* [http://www.guuui.com/browse.php?cid=152 Shopping Carts - GUUUI]

File:Actor.jpg

2008-07-26T23:27:44Z

Washao:

CSC/ECE 517 Summer 2008/wiki3 7 ws

2008-07-24T12:48:19Z

Washao:

Place holder for wei and mike wiki

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-07T18:10:35Z

Washao: /* Conclusion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] is a measure of how strongly-related and focused the various responsibilities of a software module are. It is usually expressed as “high” or “low” cohesion when being discussed. High cohesion is desired because it is robust, reliable, reusable and more understandable whereas low cohesion has the opposite of those traits – difficult to maintain, test, reuse and understand. With high cohesion comes low coupling. Coupling is the degree of dependence of internal implementation between different modules – low coupling is where the module doesn't depend on what other module's internal implementation does thus a change in them won't affect the module whereas high coupling is where a change in one module might “break” other modules because they are highly dependent on eachother's internal implementations. This page will show you different types of cohesion and coupling and examples showing the “big picture” of them.

== Cohesion ==

Cohesion is categorized in “high” and “low” but it is “measured” by how strongly-related or focused the responsibilities are for the class. In a highly-cohesive system, code readability and reusability is increased while complexity is kept manageable. A class of high cohesiveness could decrease its “cohesiveness” by carrying out more varied activities that have little in common and increasing complexity. Below we describe the different types of cohesion arranged from highest to lowest cohesion.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

=====Sequential Cohesion=====
Sequential cohesion describes modules whose operations are intended to be executed in sequence with the output of each operation providing input to the subsequently executed operation. The following example illustrates sequential cohesion.

class Cube {
public ArrayList getInfo(){
ArrayList tempList = new ArrayList();
tempList.add(getArea());
tempList.add(getVolume());
return tempList;
}
public double getArea(){return 6*side*side;}
public double getVolume(){return side*side*side;}
}

===== Information cohesion =====
Information cohesion can do several things with the same data - a class with various methods using same data. The following example illustrates information cohesion.

class Circle {
double radius;
public double getArea(){return 3.14*radius*radius;}
public double getDiameter(){return 2 * radius;}
public double getCircumference(){return 3.14*2*radius;}
}

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

=====Procedural Cohesion=====
Procedural cohesion is similar to sequential cohesion in that the operations exposed are typically grouped because they are executed within a sequence. Unlike sequential cohesion however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class Student {
public Student(int studentId) {
// implementation
}

public void LoadStudent() {
// implementation
}

public void UpdateGrades(int[] grades) {
// implementation
}

public void UpdateAttendance(Date[] dates) {
// implementation
}

public void SaveStudent() {
// implementation
}
}

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class Math {
public static int Add(int a, int b) {
// implementation
}

public static int Subtract(int a, int b) {
// implementation
}

// ...
}

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] is categorized low (loose or weak) or high (tight or strong). Low coupling is a relationship where one module interacts with another module through a stable interface and does not need to be concerned with other module's implementation. With low coupling, a change in one module will not require changes in the implementation of another module (since they are not dependent on each other). High coupling introduces problems like one module change into multiple module changes, difficulty of understanding the relationships and difficulty of testing and reusing individual modules because of high dependence. Low coupling facilitates high cohesion and vice versa. Low coupling may also reduce performance, and a highly-coupled system is sometimes desirable to achieve maximum efficiency. Below we describe the different types of coupling arranged from highest to lowest coupling.

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T02:42:31Z

Washao: /* References */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T02:41:56Z

Washao: /* Advantages */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T02:41:24Z

Washao: /* Related Concepts */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T02:40:31Z

Washao: /* Advantages and disadvantages */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T02:40:22Z

Washao: /* Coupling */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T02:38:56Z

Washao: /* Sequential Cohesion */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T02:21:08Z

Washao: /* Introduction */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T01:21:47Z

Washao: /* Cohesion */

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-06-25T01:21:34Z

Washao: /* Types of Cohesion */

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-09T17:16:28Z

Washao: /* References */

= Introduction =
A thread is a basic unit of CPU utilization. A traditional process has a single thread of control. Many modern operating systems provide features enabling a process to contain multiple threads of control. If the process has multiple threads of control, it can do more than one task at a time, such as, displaying graphics and reading keystrokes. Threads are used mainly to run asynchronous tasks and pass the application’s tasks to an executor. They are useful because they reduce the overall time of execution of programs. All threads belonging to the same process share its code section, data section and other operating system resources, such as open files and signals. Thus multithreading is more efficient than having parallel processes running for the same program, which require a huge overhead.

=Multi-threaded Programming=
Multithreading support for single processors works by giving each of the threads a “time slice” of the CPU, similar to the parallel execution of processes. On multi-core machines, different threads can run on the different processors and the threads truly run simultaneously. Support for threads may be provided at either the user level, for user or green threads, or by the kernel, for kernel or native threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

==Multi-threading Models==
There are three common multithreading models

===One-to-One===
This model maps each user-thread to a kernel thread. It provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors. The main disadvantage of this model is the overhead of creating each kernel thread for each user thread. This burdens the performance of an application and limits the number of threads supported by the system.

===Many-to-One===
This model maps many user-level threads to one kernel thread. It is the model used by green threads. Green threads are scheduled by a Virtual Machine instead of natively by the OS. They emulate multithreaded environments without relying on any native OS capabilities. These user-level threads are lightweight and very efficient. They are an easy way to achieve parallelism in a program. An application can have as many user-level threads as it needs, but true concurrency is not achieved because the kernel can schedule only one thread at a time. The developers can create as many user threads as necessary. However, there are two main disadvantages:
1) If a thread makes a blocking system call, the entire process will block.
2) If you are running on a multi-core machine, the multiple threads are unable to run in parallel.

===Many-to-Many===
This model multiplexes many user-level threads to a smaller or equal number of kernel threads. This model has the best of both worlds. Developers can create as many user threads as they need. When a user thread performs a blocking system call, the kernel can schedule another thread for execution and the kernel threads can run in parallel on multi-core systems.

==Benefits of Multi-threading==
===Resource sharing===
Memory, code and process resource sharing - allocating memory and resources for process creation is costly and time consuming. It is more economical to create threads than new processes. Applications can benefit by having several different threads of activity within the same address space.

===Responsiveness===
Multithreading an interactive application may allow a program to continue running, even if part of it is blocked doing IO or performing a lengthy operation, thereby increasing responsiveness to the user. A web browser might have one thread display images or text while another thread retrieves data from the network. A busy web server may have many clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

==Potential Problems of Multi-threading==
Many threaded programs have shared resources that must be accessed by more than one thread. These programs must implement a form of mutual exclusion to ensure that only one of the threads can access the resource at a time. These shared resources must execute in code called critical sections. These critical sections must be protected by either hardware or software means.

=Java Threads=
The Java programming language has a thread library for creating and managing threads at the user-level. The Java virtual machine (JVM) manages the mapping of the user threads to the operating system kernel threads. The particular mapping model that is used depends on the operating system on which the Java program is running. Java’s Thread Scheduler monitors all the threads running in Java programs. It decides which threads to run at any given time and when to switch between threads to run based on the thread’s priority with higher running threads running before lower priority threads. The Java scheduler uses either preemptive or non-preemptive scheduling based on the operating system on which it is running. With preemptive scheduling, each thread is given a constant period of time to run, after which time the thread will be suspended() to allow the next thread to resume() running. With non-preemptive scheduling, the running thread is allowed to run until the thread completes or until it issues a yield() to allow other threads to run while it waits for some other processing to occur.
A Java thread can be created either by having your Java class extend the Java Thread class or by having your Java class implement the Runnable interface and coding a run() method. The two options are shown in Figures 1 and 2. The preferred method for creating a thread is by implementing the Runnable interface. It is more flexible and useful in complex applications. Java does not support multiple inheritance, but a class may implement multiple interfaces. By using the interface method, the Client class is open to inherit another class, if the need arose in the future.

'''Figure 1: Client Extends Thread Class'''

public class Client extends Thread {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {
public static void main(String args[]){
Thread runner = new Client();
runner.start();
System.out.println(“Server thread”);
}
}

'''Figure 2: Client Implements Runnable Interface'''

public class Client implements Runnable {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {

public static void main(String args[]) {
Thread runner = new Thread(new Client());
runner.start();
System.out.println(“Server thread”);
}
}

If the main Java thread wants to wait for any threads it creates to finish their run() method, the thread method join() can be executed. The join() method is useful in situations where the creating thread can continue only after a worker thread has completed. Java threads can be asynchronously terminated using the stop() method. However, this method has been deprecated and its used is discouraged. The preferred cancellation technique is to have the target thread periodically check whether it should terminate by using the interrupt() method.

==States of Java Threads==
===New===
A thread is in this state when the thread object is first created with the new() method.
===Runnable===
Calling the start() method allocates memory for the new thread in the JVM and calls the run() method for the thread object.
===Blocked===
A thread becomes blocked if it performs a blocking statement, such as doing I/O or if it invokes a sleep() method.
===Dead===
A thread moves to the dead state when its run() method terminates.

==Mutual Exclusion==
The Java language implements mutual exclusion in a couple of ways. There exists a MutualExclusion interface. The Client class can implement this interface and code the methods, enteringCriticalSection() and leavingCriticalSection(), as shown in Figure 3. The yield() method tells the Thread Scheduler to allow another thread to run.

'''Figure 3: Client Implements MutualExclusion Interface'''

public class Client implements MutualExclusion{

public Client(){
flag0 = false; flag1 = false; turn = TURN_0;
}

public void enteringCriticalSection(int t) {
int other = 1 - t;

if (t == 0) {
flag0 = true; turn = other;
while ((flag1 == true) && (turn == other))
Thread.yield();
} else {
flag1 = true; turn = other;
while ((flag0 == true) && (turn == other))
Thread.yield();
}
}

public void leavingCriticalSection(int t) {
if(t == 0) flag0 = false;
else flag1 = false;
}
private volatile int turn, boolean flag0, flag1;
}

An alternative method of handling mutual exclusion is to code a synchronization tool called a semaphore. A semaphore is variable that is accessed only through two standard operations: acquire() and release(). The semaphore is acquired, then the critical section of an object is entered and after the critical code completes, the semaphore is released. An example of this code is in Figure 4.

'''Figure 4: Client Has Semaphore'''

public class Client implements Runnable {

public Client (Semaphore sem) {
this.sem = sem;
}

public void run() {
sem.acquire();
System.out.println("Entering critical section");
SleepUtilities.nap(3);
System.out.println("Leaving critical section");
sem.release();
}
private Semaphore sem;
}

=Ruby Threads=
At the present time the Ruby programming language just supports green threads. These are totally implemented within the Ruby interpreter. The threads, as well as the thread scheduler run on the same single operating system thread. Ruby can support thread methods, such as stop() and kill(), that are not advised for kernel threads. However, Ruby threads suffer from the drawbacks of non-native threads. They can only run on one processor in a multiprocessor environment. It is possible for a single thread to cause the whole process to deadlock, if poorly designed. The worse problem with Ruby threads is with I/O, especially network access, since it has the potential to block a process for a long time. This problem is solvable by using non-blocking I/O. However, one problem that is not solvable using non-blocking I/O, is the DNS lookup system call. Ruby solves this problem with their resolv library, which was written specifically to address the threading issue with the standard OS DNA lookup mechanism. See Figure 5 for an example of the code that handles this issue. Despite some of the green thread concerns, for most situations, the benefits of efficiency can far outweigh the disadvantages.

'''Figure 5: Ruby DNS Lookup Implementation'''

require ‘socket’
require ‘resolv-replace’
count = 0
Thread.critical = true
thread = Thread.new { Thread.pass; loop { count += 1; } } IPSocket.getaddress(www.ruby-lang.org)
count

A Ruby thread is created using Thread.new() {block}. The arguments given in the new() method are passed to the block code that the thread executes. See Figure 6 for an example of creating a Ruby thread. The Ruby pass() method is analogous to the Java yield() method. It tells the thread scheduler to pass execution to another thread. Ruby has a join() method that performs the same functionality as the Java join(). There are run() and wakeup() methods that wake up a sleeping threads, either giving it control or indicating that it is ready to be scheduled.

'''Figure 6: Creating Ruby Threads'''

threads = []
4.times do |number|
threads << Thread.new(number) do |i|
print “#{i}\n”
end
end
threads.each { |t| t.join }

==States of Ruby Threads==
===Run===
The thread is executing.
===Sleep===
The thread is sleeping or waiting on I/O.
===Aborting===
The thread is aborting (has been killed).
===False===
The thread has terminated normally.
===Nil===
The thread has terminated with an exception.

==Mutual Exclusion==
The best way to handle mutual exclusion in Ruby is with the Monitor class. A monitor has a synchronization() method that prevent access to a resource by another thread while one is execution in that method. Figure 7 shows an example of how this can be used.

'''Figure 7: Ruby Monitor'''

require 'monitor'
class Counter < Monitor
attr_reader :count

def initialize
@count = 0
super
end

def tick
synchronize do
@count += 1
end
end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join; t2.join
c.count

=Java vs Ruby Threads=
Java thread initialization is more involved than Ruby thread initialization. Ruby threads also have the advantage of a “quick and dirty” thread creation, since it only takes couple of lines of code. A Ruby thread shares all global, instance and local variables that are in existence at the time the thread starts. A Java thread can share these variables, as well, depending on how the thread was created. If the client thread class uses inheritance, any variables needed are passed along when creating the thread. If the thread is created through the interface, the variables can be shared as long as the class has been initialized and the variables in use.

Ruby’s green threads are completely portable, as they don’t rely on the OS. But, on a multi-core processor, native thread implementations can assign work to multiple processors while green threads cannot. In this environment native threads have a huge advantage as more work is done by the native threads.

==Java and Ruby Methods Comparison==

'''Table 1 lists thread actions and Java and Ruby’s equivalent methods of achieving them.'''

[[Image:java table1.jpg]]

'''Table 2 lists thread actions available in Java, but Ruby doesn’t have a method for the action.'''

[[Image:java table2.jpg]]

'''Table 3 lists thread actions available in Ruby, but Java doesn’t have a method for the action.'''

[[Image:java table3.jpg]]

There are many similarities between the Java and Ruby Thread classes, as shown with the equivalent methods in Table 1. But, as you can see, there are also many methods in Java that Ruby doesn't support and vice versa. Some methods like activeCount(), where it returns the number of active threads, are trivial, but there is a group of methods existing in both Java and Ruby that the other doesn't support. For Java, it is exception handling with getting/setting exceptions, while in Ruby, it is more thread control. Ruby has exception methods, but they are geared more toward events prior to the exception, like making sure all threads abort when exception starts and firing an exception to destroy threads. Java is more about setting the exceptions and getting them to change accordingly. So the Java Thread class has a little bit more exception handling than Ruby.

Ruby has more thread control for the programmer such as pausing, terminating, aborting and resuming threads. Java did have these functions, but they all have been deprecated because, although they give the user more control, they also can cause deadlock problems. So it is a tradeoff between more thread control and less chance for deadlocks to happen. Java does use interrupt to "pause" the thread as opposed to actually pausing the thread as in Ruby. Also, Java threads "sleep" differently than Ruby threads. Java sleeps are timed, while Ruby's sleep just stops the thread indefinitely, until it gets woken up by "thr.wakeup". As you can see Ruby's thread methods are more flexible, but potentially dangerous than Java’s.

Basically, Java and Ruby both have similar thread functionalities. In some respects, Java is simpler by reducing user error, while Ruby gives the programmer more power and perhaps more headaches. If user wants more control, then Ruby threading is great, but for simplicity Java is better. The main distinction between Ruby threads and Java threads are that currently Ruby just supports green threads (as did Java 1.1) and Java has support for kernel threads. Currently, there is no clear “winner” between native and green threads in a uni-processor system, but Java threads definitely have the edge over Ruby in a multi-processor environment.
Ruby is moving from green threads to kernel threads in Ruby 1.9 or 2.0, which are still development releases. YARV has been integrated as the new Ruby VM. YARV will give Ruby kernel thread support. Detailed discussions of this change are at the following links:
http://www.infoq.com/news/2007/05/ruby-threading-futures
http://expressica.com/2008/04/26/new-in-ruby-19-threads/

==Java vs. Ruby Thread Efficiency==
In order to test the efficiency of Java and Ruby threads two programs were written in each language. The first one reads in the contents of five text files, one for each of five threads, searches for a given word in each and counts each occurrence of the word. This count is added to a total count for all five files. Each file is passed to its own thread to run. The main thread has the total count, which is updated using mutual exclusion techniques in each language. The second program was modified from the first. Instead of searching for words in files, a string was passed to each thread. The times it took each to run each program depended on the size of the files, to a small extent and on the programming language to a larger extent. The results are recorded in Table 4. The file versions of these programs are given in Figures 8 and 9. With the small file, the Ruby code ran about as fast as the Java code. With the large file, the Java code ran five times faster than Ruby. This is evidence that when doing file I/O, Java's native threads are much more efficient. The string versions of these programs are not included in this Wiki. Both the Java code and the Ruby code processed the strings in approximately the same about of time. I had expected the Ruby code to outperform Java with this version.

{| border="1"
|+ Table 4: WordCounts Running Times
|-
! File Sizes
! Ruby Times
! Java Times
|-
| 10KB
| 16 millisecs
| 15 millisecs
|-
| 80KB
| 119 millisecs
| 20 millisecs
|-
! String Sizes
! Ruby Times
! Java Times
|-
| 10KB
| 15 millisecs
| 16 millisecs
|-
| 60KB
| 20 millisecs
| 22 millisecs
|}

'''Figure 8: Java Word Counts Code'''
public class WordCounts {
protected static int wordCount;

private class Semaphore {
private int mutex;

public Semaphore () {
mutex = 1;
}

public synchronized void acquire() throws InterruptedException {
while (mutex == 0) {
wait();
}
mutex--;
}
public synchronized void release() {
mutex++;
notifyAll();
}
}

private class WordCountsThread implements Runnable {
private String word;
private String file;
private int count;
private Semaphore total;

public WordCountsThread (String word, String file, Semaphore total) {
this.word = word;
this.file = file;
this.total = total;
count = 0;
}

public void run(){
readWordFile();

try {
total.acquire();
wordCount = wordCount + count;
total.release();
} catch (InterruptedException e) {
System.out.println (e);
}
}

private void readWordFile (){
} // end method
} //end inner class: WordCountThread

public WordCounts (String searchWord, String [] files) {
int numFiles = files.length;
Semaphore total = new Semaphore();
Thread [] threads = new Thread [numFiles];

for (int i = 0; i < numFiles; i++ ) {
threads[i] = new Thread (new WordCountsThread (searchWord,files[i], total));
}

for (int j = 0; j < numFiles; j++ ) {
threads[j].start();
}

try {
for (int i = 0; i < numFiles; i++ ) {
threads[i].join();
}
} catch (InterruptedException e) {
System.out.println (e);
}
}

public void displayTotal (String searchWord) {
System.out.println ("There are " + wordCount +
" total occurrences of " + searchWord);
}

public static void main (String [] args) {
String [] files;
files = new String [5];
files [0] = "Player.java";
files [1] = "KingMove.java";
files [2] = "NodeDeque.java";
files [3] = "Position.java";
files [4] = "DoubleDigest.java";
String searchWord = "public";
long time = System.currentTimeMillis (), time_prev = time;
WordCounts wc = new WordCounts (searchWord, files);
wc.displayTotal (searchWord);
time = System.currentTimeMillis ();
System.out.println ("Diff " + (time - time_prev) + " msecs");
System.exit(0);
}
}

'''Figure 9: Ruby Word Counts Code'''

class WordCounts < Monitor
attr_reader :wordCount, :numFiles, :searchWord

def initialize
super
end # initialize def

def initVars(files, searchWord)
@wordCount = 0
@files = files
@searchWord = searchWord
end # initVars

def countWordsInFiles
threads = []

for fileToFetch in @files
threads << Thread.new(fileToFetch) do |file|
count = readWordFile(file)
updateTotal(count)
end
end
threads.each {|t| t.join}
end # countWordsInFiles

def readWordFile(file)
...
puts ("There are " + count.to_s + " occurrences of '" + @searchWord[0] + "' in " + file + "\n")
return count
end # readWordFile def

def displayTotal
puts ("\nThere are " + @wordCount.to_s + " total occurrences of '" + @searchWord[0] + "'")
end # displayTotal def

def updateTotal (count)
synchronize do
@wordCount += count
end
end # updateTotal def
end # WordCounts class def

files = %w( Player.java KingMove.java NodeDeque.java Position.java DoubleDigest.java)
searchWord = %w( public )
wc = WordCounts.new
wc.initVars(files, searchWord)
ustart = Time.now.usec
wc.countWordsInFiles
wc.displayTotal
t = Time.now
uend = Time.now.usec
puts ("Start: " + ustart.to_s + " usecs")
puts ("End: " + uend.to_s + " usecs")
puts ("diff: " + ((uend - ustart)/1000.0).to_s + " msecs")

=References=

http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_threads.html

http://www.ruby-doc.org/core/classes/Thread.html

http://phrogz.net/ProgrammingRuby/ref_c_thread.html

http://www.javaworld.com/javaworld/jw-04-1996/jw-04-threads.html

http://java.sun.com/javase/6/docs/api/java/lang/Thread.html

http://en.wikipedia.org/wiki/Green_threads

http://corelib.rubyonrails.com/classes/Thread.html

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-09T17:15:43Z

Washao: /* References */

= Introduction =
A thread is a basic unit of CPU utilization. A traditional process has a single thread of control. Many modern operating systems provide features enabling a process to contain multiple threads of control. If the process has multiple threads of control, it can do more than one task at a time, such as, displaying graphics and reading keystrokes. Threads are used mainly to run asynchronous tasks and pass the application’s tasks to an executor. They are useful because they reduce the overall time of execution of programs. All threads belonging to the same process share its code section, data section and other operating system resources, such as open files and signals. Thus multithreading is more efficient than having parallel processes running for the same program, which require a huge overhead.

=Multi-threaded Programming=
Multithreading support for single processors works by giving each of the threads a “time slice” of the CPU, similar to the parallel execution of processes. On multi-core machines, different threads can run on the different processors and the threads truly run simultaneously. Support for threads may be provided at either the user level, for user or green threads, or by the kernel, for kernel or native threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

==Multi-threading Models==
There are three common multithreading models

===One-to-One===
This model maps each user-thread to a kernel thread. It provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors. The main disadvantage of this model is the overhead of creating each kernel thread for each user thread. This burdens the performance of an application and limits the number of threads supported by the system.

===Many-to-One===
This model maps many user-level threads to one kernel thread. It is the model used by green threads. Green threads are scheduled by a Virtual Machine instead of natively by the OS. They emulate multithreaded environments without relying on any native OS capabilities. These user-level threads are lightweight and very efficient. They are an easy way to achieve parallelism in a program. An application can have as many user-level threads as it needs, but true concurrency is not achieved because the kernel can schedule only one thread at a time. The developers can create as many user threads as necessary. However, there are two main disadvantages:
1) If a thread makes a blocking system call, the entire process will block.
2) If you are running on a multi-core machine, the multiple threads are unable to run in parallel.

===Many-to-Many===
This model multiplexes many user-level threads to a smaller or equal number of kernel threads. This model has the best of both worlds. Developers can create as many user threads as they need. When a user thread performs a blocking system call, the kernel can schedule another thread for execution and the kernel threads can run in parallel on multi-core systems.

==Benefits of Multi-threading==
===Resource sharing===
Memory, code and process resource sharing - allocating memory and resources for process creation is costly and time consuming. It is more economical to create threads than new processes. Applications can benefit by having several different threads of activity within the same address space.

===Responsiveness===
Multithreading an interactive application may allow a program to continue running, even if part of it is blocked doing IO or performing a lengthy operation, thereby increasing responsiveness to the user. A web browser might have one thread display images or text while another thread retrieves data from the network. A busy web server may have many clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

==Potential Problems of Multi-threading==
Many threaded programs have shared resources that must be accessed by more than one thread. These programs must implement a form of mutual exclusion to ensure that only one of the threads can access the resource at a time. These shared resources must execute in code called critical sections. These critical sections must be protected by either hardware or software means.

=Java Threads=
The Java programming language has a thread library for creating and managing threads at the user-level. The Java virtual machine (JVM) manages the mapping of the user threads to the operating system kernel threads. The particular mapping model that is used depends on the operating system on which the Java program is running. Java’s Thread Scheduler monitors all the threads running in Java programs. It decides which threads to run at any given time and when to switch between threads to run based on the thread’s priority with higher running threads running before lower priority threads. The Java scheduler uses either preemptive or non-preemptive scheduling based on the operating system on which it is running. With preemptive scheduling, each thread is given a constant period of time to run, after which time the thread will be suspended() to allow the next thread to resume() running. With non-preemptive scheduling, the running thread is allowed to run until the thread completes or until it issues a yield() to allow other threads to run while it waits for some other processing to occur.
A Java thread can be created either by having your Java class extend the Java Thread class or by having your Java class implement the Runnable interface and coding a run() method. The two options are shown in Figures 1 and 2. The preferred method for creating a thread is by implementing the Runnable interface. It is more flexible and useful in complex applications. Java does not support multiple inheritance, but a class may implement multiple interfaces. By using the interface method, the Client class is open to inherit another class, if the need arose in the future.

'''Figure 1: Client Extends Thread Class'''

public class Client extends Thread {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {
public static void main(String args[]){
Thread runner = new Client();
runner.start();
System.out.println(“Server thread”);
}
}

'''Figure 2: Client Implements Runnable Interface'''

public class Client implements Runnable {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {

public static void main(String args[]) {
Thread runner = new Thread(new Client());
runner.start();
System.out.println(“Server thread”);
}
}

If the main Java thread wants to wait for any threads it creates to finish their run() method, the thread method join() can be executed. The join() method is useful in situations where the creating thread can continue only after a worker thread has completed. Java threads can be asynchronously terminated using the stop() method. However, this method has been deprecated and its used is discouraged. The preferred cancellation technique is to have the target thread periodically check whether it should terminate by using the interrupt() method.

==States of Java Threads==
===New===
A thread is in this state when the thread object is first created with the new() method.
===Runnable===
Calling the start() method allocates memory for the new thread in the JVM and calls the run() method for the thread object.
===Blocked===
A thread becomes blocked if it performs a blocking statement, such as doing I/O or if it invokes a sleep() method.
===Dead===
A thread moves to the dead state when its run() method terminates.

==Mutual Exclusion==
The Java language implements mutual exclusion in a couple of ways. There exists a MutualExclusion interface. The Client class can implement this interface and code the methods, enteringCriticalSection() and leavingCriticalSection(), as shown in Figure 3. The yield() method tells the Thread Scheduler to allow another thread to run.

'''Figure 3: Client Implements MutualExclusion Interface'''

public class Client implements MutualExclusion{

public Client(){
flag0 = false; flag1 = false; turn = TURN_0;
}

public void enteringCriticalSection(int t) {
int other = 1 - t;

if (t == 0) {
flag0 = true; turn = other;
while ((flag1 == true) && (turn == other))
Thread.yield();
} else {
flag1 = true; turn = other;
while ((flag0 == true) && (turn == other))
Thread.yield();
}
}

public void leavingCriticalSection(int t) {
if(t == 0) flag0 = false;
else flag1 = false;
}
private volatile int turn, boolean flag0, flag1;
}

An alternative method of handling mutual exclusion is to code a synchronization tool called a semaphore. A semaphore is variable that is accessed only through two standard operations: acquire() and release(). The semaphore is acquired, then the critical section of an object is entered and after the critical code completes, the semaphore is released. An example of this code is in Figure 4.

'''Figure 4: Client Has Semaphore'''

public class Client implements Runnable {

public Client (Semaphore sem) {
this.sem = sem;
}

public void run() {
sem.acquire();
System.out.println("Entering critical section");
SleepUtilities.nap(3);
System.out.println("Leaving critical section");
sem.release();
}
private Semaphore sem;
}

=Ruby Threads=
At the present time the Ruby programming language just supports green threads. These are totally implemented within the Ruby interpreter. The threads, as well as the thread scheduler run on the same single operating system thread. Ruby can support thread methods, such as stop() and kill(), that are not advised for kernel threads. However, Ruby threads suffer from the drawbacks of non-native threads. They can only run on one processor in a multiprocessor environment. It is possible for a single thread to cause the whole process to deadlock, if poorly designed. The worse problem with Ruby threads is with I/O, especially network access, since it has the potential to block a process for a long time. This problem is solvable by using non-blocking I/O. However, one problem that is not solvable using non-blocking I/O, is the DNS lookup system call. Ruby solves this problem with their resolv library, which was written specifically to address the threading issue with the standard OS DNA lookup mechanism. See Figure 5 for an example of the code that handles this issue. Despite some of the green thread concerns, for most situations, the benefits of efficiency can far outweigh the disadvantages.

'''Figure 5: Ruby DNS Lookup Implementation'''

require ‘socket’
require ‘resolv-replace’
count = 0
Thread.critical = true
thread = Thread.new { Thread.pass; loop { count += 1; } } IPSocket.getaddress(www.ruby-lang.org)
count

A Ruby thread is created using Thread.new() {block}. The arguments given in the new() method are passed to the block code that the thread executes. See Figure 6 for an example of creating a Ruby thread. The Ruby pass() method is analogous to the Java yield() method. It tells the thread scheduler to pass execution to another thread. Ruby has a join() method that performs the same functionality as the Java join(). There are run() and wakeup() methods that wake up a sleeping threads, either giving it control or indicating that it is ready to be scheduled.

'''Figure 6: Creating Ruby Threads'''

threads = []
4.times do |number|
threads << Thread.new(number) do |i|
print “#{i}\n”
end
end
threads.each { |t| t.join }

==States of Ruby Threads==
===Run===
The thread is executing.
===Sleep===
The thread is sleeping or waiting on I/O.
===Aborting===
The thread is aborting (has been killed).
===False===
The thread has terminated normally.
===Nil===
The thread has terminated with an exception.

==Mutual Exclusion==
The best way to handle mutual exclusion in Ruby is with the Monitor class. A monitor has a synchronization() method that prevent access to a resource by another thread while one is execution in that method. Figure 7 shows an example of how this can be used.

'''Figure 7: Ruby Monitor'''

require 'monitor'
class Counter < Monitor
attr_reader :count

def initialize
@count = 0
super
end

def tick
synchronize do
@count += 1
end
end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join; t2.join
c.count

=Java vs Ruby Threads=
Java thread initialization is more involved than Ruby thread initialization. Ruby threads also have the advantage of a “quick and dirty” thread creation, since it only takes couple of lines of code. A Ruby thread shares all global, instance and local variables that are in existence at the time the thread starts. A Java thread can share these variables, as well, depending on how the thread was created. If the client thread class uses inheritance, any variables needed are passed along when creating the thread. If the thread is created through the interface, the variables can be shared as long as the class has been initialized and the variables in use.

Ruby’s green threads are completely portable, as they don’t rely on the OS. But, on a multi-core processor, native thread implementations can assign work to multiple processors while green threads cannot. In this environment native threads have a huge advantage as more work is done by the native threads.

==Java and Ruby Methods Comparison==

'''Table 1 lists thread actions and Java and Ruby’s equivalent methods of achieving them.'''

[[Image:java table1.jpg]]

'''Table 2 lists thread actions available in Java, but Ruby doesn’t have a method for the action.'''

[[Image:java table2.jpg]]

'''Table 3 lists thread actions available in Ruby, but Java doesn’t have a method for the action.'''

[[Image:java table3.jpg]]

There are many similarities between the Java and Ruby Thread classes, as shown with the equivalent methods in Table 1. But, as you can see, there are also many methods in Java that Ruby doesn't support and vice versa. Some methods like activeCount(), where it returns the number of active threads, are trivial, but there is a group of methods existing in both Java and Ruby that the other doesn't support. For Java, it is exception handling with getting/setting exceptions, while in Ruby, it is more thread control. Ruby has exception methods, but they are geared more toward events prior to the exception, like making sure all threads abort when exception starts and firing an exception to destroy threads. Java is more about setting the exceptions and getting them to change accordingly. So the Java Thread class has a little bit more exception handling than Ruby.

Ruby has more thread control for the programmer such as pausing, terminating, aborting and resuming threads. Java did have these functions, but they all have been deprecated because, although they give the user more control, they also can cause deadlock problems. So it is a tradeoff between more thread control and less chance for deadlocks to happen. Java does use interrupt to "pause" the thread as opposed to actually pausing the thread as in Ruby. Also, Java threads "sleep" differently than Ruby threads. Java sleeps are timed, while Ruby's sleep just stops the thread indefinitely, until it gets woken up by "thr.wakeup". As you can see Ruby's thread methods are more flexible, but potentially dangerous than Java’s.

Basically, Java and Ruby both have similar thread functionalities. In some respects, Java is simpler by reducing user error, while Ruby gives the programmer more power and perhaps more headaches. If user wants more control, then Ruby threading is great, but for simplicity Java is better. The main distinction between Ruby threads and Java threads are that currently Ruby just supports green threads (as did Java 1.1) and Java has support for kernel threads. Currently, there is no clear “winner” between native and green threads in a uni-processor system, but Java threads definitely have the edge over Ruby in a multi-processor environment.
Ruby is moving from green threads to kernel threads in Ruby 1.9 or 2.0, which are still development releases. YARV has been integrated as the new Ruby VM. YARV will give Ruby kernel thread support. Detailed discussions of this change are at the following links:
http://www.infoq.com/news/2007/05/ruby-threading-futures
http://expressica.com/2008/04/26/new-in-ruby-19-threads/

==Java vs. Ruby Thread Efficiency==
In order to test the efficiency of Java and Ruby threads two programs were written in each language. The first one reads in the contents of five text files, one for each of five threads, searches for a given word in each and counts each occurrence of the word. This count is added to a total count for all five files. Each file is passed to its own thread to run. The main thread has the total count, which is updated using mutual exclusion techniques in each language. The second program was modified from the first. Instead of searching for words in files, a string was passed to each thread. The times it took each to run each program depended on the size of the files, to a small extent and on the programming language to a larger extent. The results are recorded in Table 4. The file versions of these programs are given in Figures 8 and 9. With the small file, the Ruby code ran about as fast as the Java code. With the large file, the Java code ran five times faster than Ruby. This is evidence that when doing file I/O, Java's native threads are much more efficient. The string versions of these programs are not included in this Wiki. Both the Java code and the Ruby code processed the strings in approximately the same about of time. I had expected the Ruby code to outperform Java with this version.

{| border="1"
|+ Table 4: WordCounts Running Times
|-
! File Sizes
! Ruby Times
! Java Times
|-
| 10KB
| 16 millisecs
| 15 millisecs
|-
| 80KB
| 119 millisecs
| 20 millisecs
|-
! String Sizes
! Ruby Times
! Java Times
|-
| 10KB
| 15 millisecs
| 16 millisecs
|-
| 60KB
| 20 millisecs
| 22 millisecs
|}

'''Figure 8: Java Word Counts Code'''
public class WordCounts {
protected static int wordCount;

private class Semaphore {
private int mutex;

public Semaphore () {
mutex = 1;
}

public synchronized void acquire() throws InterruptedException {
while (mutex == 0) {
wait();
}
mutex--;
}
public synchronized void release() {
mutex++;
notifyAll();
}
}

private class WordCountsThread implements Runnable {
private String word;
private String file;
private int count;
private Semaphore total;

public WordCountsThread (String word, String file, Semaphore total) {
this.word = word;
this.file = file;
this.total = total;
count = 0;
}

public void run(){
readWordFile();

try {
total.acquire();
wordCount = wordCount + count;
total.release();
} catch (InterruptedException e) {
System.out.println (e);
}
}

private void readWordFile (){
} // end method
} //end inner class: WordCountThread

public WordCounts (String searchWord, String [] files) {
int numFiles = files.length;
Semaphore total = new Semaphore();
Thread [] threads = new Thread [numFiles];

for (int i = 0; i < numFiles; i++ ) {
threads[i] = new Thread (new WordCountsThread (searchWord,files[i], total));
}

for (int j = 0; j < numFiles; j++ ) {
threads[j].start();
}

try {
for (int i = 0; i < numFiles; i++ ) {
threads[i].join();
}
} catch (InterruptedException e) {
System.out.println (e);
}
}

public void displayTotal (String searchWord) {
System.out.println ("There are " + wordCount +
" total occurrences of " + searchWord);
}

public static void main (String [] args) {
String [] files;
files = new String [5];
files [0] = "Player.java";
files [1] = "KingMove.java";
files [2] = "NodeDeque.java";
files [3] = "Position.java";
files [4] = "DoubleDigest.java";
String searchWord = "public";
long time = System.currentTimeMillis (), time_prev = time;
WordCounts wc = new WordCounts (searchWord, files);
wc.displayTotal (searchWord);
time = System.currentTimeMillis ();
System.out.println ("Diff " + (time - time_prev) + " msecs");
System.exit(0);
}
}

'''Figure 9: Ruby Word Counts Code'''

class WordCounts < Monitor
attr_reader :wordCount, :numFiles, :searchWord

def initialize
super
end # initialize def

def initVars(files, searchWord)
@wordCount = 0
@files = files
@searchWord = searchWord
end # initVars

def countWordsInFiles
threads = []

for fileToFetch in @files
threads << Thread.new(fileToFetch) do |file|
count = readWordFile(file)
updateTotal(count)
end
end
threads.each {|t| t.join}
end # countWordsInFiles

def readWordFile(file)
...
puts ("There are " + count.to_s + " occurrences of '" + @searchWord[0] + "' in " + file + "\n")
return count
end # readWordFile def

def displayTotal
puts ("\nThere are " + @wordCount.to_s + " total occurrences of '" + @searchWord[0] + "'")
end # displayTotal def

def updateTotal (count)
synchronize do
@wordCount += count
end
end # updateTotal def
end # WordCounts class def

files = %w( Player.java KingMove.java NodeDeque.java Position.java DoubleDigest.java)
searchWord = %w( public )
wc = WordCounts.new
wc.initVars(files, searchWord)
ustart = Time.now.usec
wc.countWordsInFiles
wc.displayTotal
t = Time.now
uend = Time.now.usec
puts ("Start: " + ustart.to_s + " usecs")
puts ("End: " + uend.to_s + " usecs")
puts ("diff: " + ((uend - ustart)/1000.0).to_s + " msecs")

=References=

http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_threads.html
http://www.ruby-doc.org/core/classes/Thread.html
http://phrogz.net/ProgrammingRuby/ref_c_thread.html
http://www.javaworld.com/javaworld/jw-04-1996/jw-04-threads.html
http://java.sun.com/javase/6/docs/api/java/lang/Thread.html
http://en.wikipedia.org/wiki/Green_threads
http://corelib.rubyonrails.com/classes/Thread.html

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-09T16:49:18Z

Washao:

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:54:01Z

Washao: /* Java vs. Ruby Thread Efficiency */

= Introduction =
A thread is a basic unit of CPU utilization. A traditional process has a single thread of control. Many modern operating systems provide features enabling a process to contain multiple threads of control. If the process has multiple threads of control, it can do more than one task at a time, such as, displaying graphics and reading keystrokes. Threads are used mainly to run asynchronous tasks and pass the application’s tasks to an executor. They are useful because they reduce the overall time of execution of programs. All threads belonging to the same process share its code section, data section and other operating system resources, such as open files and signals. Thus multithreading is more efficient than having parallel processes running for the same program, which require a huge overhead.

=Multi-threaded Programming=
Multithreading support for single processors works by giving each of the threads a “time slice” of the CPU, similar to the parallel execution of processes. On multi-core machines, different threads can run on the different processors and the threads truly run simultaneously. Support for threads may be provided at either the user level, for user or green threads, or by the kernel, for kernel or native threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

==Multi-threading Models==
There are three common multithreading models

===One-to-One===
This model maps each user-thread to a kernel thread. It provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors. The main disadvantage of this model is the overhead of creating each kernel thread for each user thread. This burdens the performance of an application and limits the number of threads supported by the system.

===Many-to-One===
This model maps many user-level threads to one kernel thread. It is the model used by green threads. Green threads are scheduled by a Virtual Machine instead of natively by the OS. They emulate multithreaded environments without relying on any native OS capabilities. These user-level threads are lightweight and very efficient. They are an easy way to achieve parallelism in a program. An application can have as many user-level threads as it needs, but true concurrency is not achieved because the kernel can schedule only one thread at a time. The developers can create as many user threads as necessary. However, there are two main disadvantages:
1) If a thread makes a blocking system call, the entire process will block.
2) If you are running on a multi-core machine, the multiple threads are unable to run in parallel.

===Many-to-Many===
This model multiplexes many user-level threads to a smaller or equal number of kernel threads. This model has the best of both worlds. Developers can create as many user threads as they need. When a user thread performs a blocking system call, the kernel can schedule another thread for execution and the kernel threads can run in parallel on multi-core systems.

==Benefits of Multi-threading==
===Resource sharing===
Memory, code and process resource sharing - allocating memory and resources for process creation is costly and time consuming. It is more economical to create threads than new processes. Applications can benefit by having several different threads of activity within the same address space.

===Responsiveness===
Multithreading an interactive application may allow a program to continue running, even if part of it is blocked doing IO or performing a lengthy operation, thereby increasing responsiveness to the user. A web browser might have one thread display images or text while another thread retrieves data from the network. A busy web server may have many clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

==Potential Problems of Multi-threading==
Many threaded programs have shared resources that must be accessed by more than one thread. These programs must implement a form of mutual exclusion to ensure that only one of the threads can access the resource at a time. These shared resources must execute in code called critical sections. These critical sections must be protected by either hardware or software means.

=Java Threads=
The Java programming language has a thread library for creating and managing threads at the user-level. The Java virtual machine (JVM) manages the mapping of the user threads to the operating system kernel threads. The particular mapping model that is used depends on the operating system on which the Java program is running. Java’s Thread Scheduler monitors all the threads running in Java programs. It decides which threads to run at any given time and when to switch between threads to run based on the thread’s priority with higher running threads running before lower priority threads. The Java scheduler uses either preemptive or non-preemptive scheduling based on the operating system on which it is running. With preemptive scheduling, each thread is given a constant period of time to run, after which time the thread will be suspended() to allow the next thread to resume() running. With non-preemptive scheduling, the running thread is allowed to run until the thread completes or until it issues a yield() to allow other threads to run while it waits for some other processing to occur.
A Java thread can be created either by having your Java class extend the Java Thread class or by having your Java class implement the Runnable interface and coding a run() method. The two options are shown in Figures 1 and 2. The preferred method for creating a thread is by implementing the Runnable interface. It is more flexible and useful in complex applications. Java does not support multiple inheritance, but a class may implement multiple interfaces. By using the interface method, the Client class is open to inherit another class, if the need arose in the future.

'''Figure 1: Client Extends Thread Class'''

public class Client extends Thread {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {
public static void main(String args[]){
Thread runner = new Client();
runner.start();
System.out.println(“Server thread”);
}
}

'''Figure 2: Client Implements Runnable Interface'''

public class Client implements Runnable {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {

public static void main(String args[]) {
Thread runner = new Thread(new Client());
runner.start();
System.out.println(“Server thread”);
}
}

If the main Java thread wants to wait for any threads it creates to finish their run() method, the thread method join() can be executed. The join() method is useful in situations where the creating thread can continue only after a worker thread has completed. Java threads can be asynchronously terminated using the stop() method. However, this method has been deprecated and its used is discouraged. The preferred cancellation technique is to have the target thread periodically check whether it should terminate by using the interrupt() method.

==States of Java Threads==
===New===
A thread is in this state when the thread object is first created with the new() method.
===Runnable===
Calling the start() method allocates memory for the new thread in the JVM and calls the run() method for the thread object.
===Blocked===
A thread becomes blocked if it performs a blocking statement, such as doing I/O or if it invokes a sleep() method.
===Dead===
A thread moves to the dead state when its run() method terminates.

==Mutual Exclusion==
The Java language implements mutual exclusion in a couple of ways. There exists a MutualExclusion interface. The Client class can implement this interface and code the methods, enteringCriticalSection() and leavingCriticalSection(), as shown in Figure 3. The yield() method tells the Thread Scheduler to allow another thread to run.

'''Figure 3: Client Implements MutualExclusion Interface'''

public class Client implements MutualExclusion{

public Client(){
flag0 = false; flag1 = false; turn = TURN_0;
}

public void enteringCriticalSection(int t) {
int other = 1 - t;

if (t == 0) {
flag0 = true; turn = other;
while ((flag1 == true) && (turn == other))
Thread.yield();
} else {
flag1 = true; turn = other;
while ((flag0 == true) && (turn == other))
Thread.yield();
}
}

public void leavingCriticalSection(int t) {
if(t == 0) flag0 = false;
else flag1 = false;
}
private volatile int turn, boolean flag0, flag1;
}

An alternative method of handling mutual exclusion is to code a synchronization tool called a semaphore. A semaphore is variable that is accessed only through two standard operations: acquire() and release(). The semaphore is acquired, then the critical section of an object is entered and after the critical code completes, the semaphore is released. An example of this code is in Figure 4.

'''Figure 4: Client Has Semaphore'''

public class Client implements Runnable {

public Client (Semaphore sem) {
this.sem = sem;
}

public void run() {
sem.acquire();
System.out.println("Entering critical section");
SleepUtilities.nap(3);
System.out.println("Leaving critical section");
sem.release();
}
private Semaphore sem;
}

=Ruby Threads=
At the present time the Ruby programming language just supports green threads. These are totally implemented within the Ruby interpreter. The threads, as well as the thread scheduler run on the same single operating system thread. Ruby can support thread methods, such as stop() and kill(), that are not advised for kernel threads. However, Ruby threads suffer from the drawbacks of non-native threads. They can only run on one processor in a multiprocessor environment. It is possible for a single thread to cause the whole process to deadlock, if poorly designed. The worse problem with Ruby threads is with I/O, especially network access, since it has the potential to block a process for a long time. This problem is solvable by using non-blocking I/O. However, one problem that is not solvable using non-blocking I/O, is the DNS lookup system call. Ruby solves this problem with their resolv library, which was written specifically to address the threading issue with the standard OS DNA lookup mechanism. See Figure 5 for an example of the code that handles this issue. Despite some of the green thread concerns, for most situations, the benefits of efficiency can far outweigh the disadvantages.

'''Figure 5: Ruby DNS Lookup Implementation'''

require ‘socket’
require ‘resolv-replace’
count = 0
Thread.critical = true
thread = Thread.new { Thread.pass; loop { count += 1; } } IPSocket.getaddress(www.ruby-lang.org)
count

A Ruby thread is created using Thread.new() {block}. The arguments given in the new() method are passed to the block code that the thread executes. See Figure 6 for an example of creating a Ruby thread. The Ruby pass() method is analogous to the Java yield() method. It tells the thread scheduler to pass execution to another thread. Ruby has a join() method that performs the same functionality as the Java join(). There are run() and wakeup() methods that wake up a sleeping threads, either giving it control or indicating that it is ready to be scheduled.

'''Figure 6: Creating Ruby Threads'''

threads = []
4.times do |number|
threads << Thread.new(number) do |i|
print “#{i}\n”
end
end
threads.each { |t| t.join }

==States of Ruby Threads==
===Run===
The thread is executing.
===Sleep===
The thread is sleeping or waiting on I/O.
===Aborting===
The thread is aborting (has been killed).
===False===
The thread has terminated normally.
===Nil===
The thread has terminated with an exception.

==Mutual Exclusion==
The best way to handle mutual exclusion in Ruby is with the Monitor class. A monitor has a synchronization() method that prevent access to a resource by another thread while one is execution in that method. Figure 7 shows an example of how this can be used.

'''Figure 7: Ruby Monitor'''

require 'monitor'
class Counter < Monitor
attr_reader :count

def initialize
@count = 0
super
end

def tick
synchronize do
@count += 1
end
end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join; t2.join
c.count

=Java vs Ruby Threads=
Java thread initialization is more involved than Ruby thread initialization. Ruby threads also have the advantage of a “quick and dirty” thread creation, since it only takes couple of lines of code. A Ruby thread shares all global, instance and local variables that are in existence at the time the thread starts. A Java thread can share these variables, as well, depending on how the thread was created. If the client thread class uses inheritance, any variables needed are passed along when creating the thread. If the thread is created through the interface, the variables can be shared as long as the class has been initialized and the variables in use.

Ruby’s green threads are completely portable, as they don’t rely on the OS. But, on a multi-core processor, native thread implementations can assign work to multiple processors while green threads cannot. In this environment native threads have a huge advantage as more work is done by the native threads.

==Java and Ruby Methods Comparison==

'''Table 1 lists thread actions and Java and Ruby’s equivalent methods of achieving them.'''

[[Image:java table1.jpg]]

'''Table 2 lists thread actions available in Java, but Ruby doesn’t have a method for the action.'''

[[Image:java table2.jpg]]

'''Table 3 lists thread actions available in Ruby, but Java doesn’t have a method for the action.'''

[[Image:java table3.jpg]]

There are many similarities between the Java and Ruby Thread classes, as shown with the equivalent methods in Table 1. But, as you can see, there are also many methods in Java that Ruby doesn't support and vice versa. Some methods like activeCount(), where it returns the number of active threads, are trivial, but there is a group of methods existing in both Java and Ruby that the other doesn't support. For Java, it is exception handling with getting/setting exceptions, while in Ruby, it is more thread control. Ruby has exception methods, but they are geared more toward events prior to the exception, like making sure all threads abort when exception starts and firing an exception to destroy threads. Java is more about setting the exceptions and getting them to change accordingly. So the Java Thread class has a little bit more exception handling than Ruby.

Ruby has more thread control for the programmer such as pausing, terminating, aborting and resuming threads. Java did have these functions, but they all have been deprecated because, although they give the user more control, they also can cause deadlock problems. So it is a tradeoff between more thread control and less chance for deadlocks to happen. Java does use interrupt to "pause" the thread as opposed to actually pausing the thread as in Ruby. Also, Java threads "sleep" differently than Ruby threads. Java sleeps are timed, while Ruby's sleep just stops the thread indefinitely, until it gets woken up by "thr.wakeup". As you can see Ruby's thread methods are more flexible, but potentially dangerous than Java’s.

Basically, Java and Ruby both have similar thread functionalities. In some respects, Java is simpler by reducing user error, while Ruby gives the programmer more power and perhaps more headaches. If user wants more control, then Ruby threading is great, but for simplicity Java is better. The main distinction between Ruby threads and Java threads are that currently Ruby just supports green threads (as did Java 1.1) and Java has support for kernel threads. Currently, there is no clear “winner” between native and green threads in a uni-processor system, but Java threads definitely have the edge over Ruby in a multi-processor environment.
Ruby is moving from green threads to kernel threads in Ruby 1.9 or 2.0, which are still development releases. YARV has been integrated as the new Ruby VM. YARV will give Ruby kernel thread support. Detailed discussions of this change are at the following links:
http://www.infoq.com/news/2007/05/ruby-threading-futures
http://expressica.com/2008/04/26/new-in-ruby-19-threads/

==Java vs. Ruby Thread Efficiency==
In order to test the efficiency of Java and Ruby threads a program was written in each language that reads in the contents of five different text files and searches for a given word in each and counts each occurrence of the word. This count is then added to a total count for all five files. Each file is passed to its own thread to run. The main thread has the total count, which is updated using mutual exclusion techniques in each language. The times it took each to run depended on the size of the files. The results are recorded in Table 4. With very small files, the Ruby code ran twice as fast of the Java. With the medium sized files the Java ran twice as fast as the Ruby code. With the larger files, the Java code ran three times faster. Certainly, the Java threads outperform the Ruby threads with I/O intensive code. The Java code is in Figure 8 and the Ruby code is in Figure 9.

'''Figure 8: Java Word Counts Code'''
public class WordCounts {
protected static int wordCount;

private class Semaphore {
private int mutex;

public Semaphore () {
mutex = 1;
}

public synchronized void acquire() throws InterruptedException {
while (mutex == 0) {
wait();
}
mutex--;
}
public synchronized void release() {
mutex++;
notifyAll();
}
}

private class WordCountsThread implements Runnable {
private String word;
private String file;
private int count;
private Semaphore total;

public WordCountsThread (String word, String file, Semaphore total) {
this.word = word;
this.file = file;
this.total = total;
count = 0;
}

public void run(){
readWordFile();

try {
total.acquire();
wordCount = wordCount + count;
total.release();
} catch (InterruptedException e) {
System.out.println (e);
}
}

private void readWordFile (){
} // end method
} //end inner class: WordCountThread

public WordCounts (String searchWord, String [] files) {
int numFiles = files.length;
Semaphore total = new Semaphore();
Thread [] threads = new Thread [numFiles];

for (int i = 0; i < numFiles; i++ ) {
threads[i] = new Thread (new WordCountsThread (searchWord,files[i], total));
}

for (int j = 0; j < numFiles; j++ ) {
threads[j].start();
}

try {
for (int i = 0; i < numFiles; i++ ) {
threads[i].join();
}
} catch (InterruptedException e) {
System.out.println (e);
}
}

public void displayTotal (String searchWord) {
System.out.println ("There are " + wordCount +
" total occurrences of " + searchWord);
}

public static void main (String [] args) {
String [] files;
files = new String [5];
files [0] = "Player.java";
files [1] = "KingMove.java";
files [2] = "NodeDeque.java";
files [3] = "Position.java";
files [4] = "DoubleDigest.java";
String searchWord = "public";
long time = System.currentTimeMillis (), time_prev = time;
WordCounts wc = new WordCounts (searchWord, files);
wc.displayTotal (searchWord);
time = System.currentTimeMillis ();
System.out.println ("Diff " + (time - time_prev) + " msecs");
System.exit(0);
}
}

'''Figure 9: Ruby Word Counts Code'''

class WordCounts < Monitor
attr_reader :wordCount, :numFiles, :searchWord

def initialize
super
end # initialize def

def initVars(files, searchWord)
@wordCount = 0
@files = files
@searchWord = searchWord
end # initVars

def countWordsInFiles
threads = []

for fileToFetch in @files
threads << Thread.new(fileToFetch) do |file|
count = readWordFile(file)
updateTotal(count)
end
end
threads.each {|t| t.join}
end # countWordsInFiles

def readWordFile(file)
...
puts ("There are " + count.to_s + " occurrences of '" + @searchWord[0] + "' in " + file + "\n")
return count
end # readWordFile def

def displayTotal
puts ("\nThere are " + @wordCount.to_s + " total occurrences of '" + @searchWord[0] + "'")
end # displayTotal def

def updateTotal (count)
synchronize do
@wordCount += count
end
end # updateTotal def
end # WordCounts class def

files = %w( Player.java KingMove.java NodeDeque.java Position.java DoubleDigest.java)
searchWord = %w( public )
wc = WordCounts.new
wc.initVars(files, searchWord)
ustart = Time.now.usec
wc.countWordsInFiles
wc.displayTotal
t = Time.now
uend = Time.now.usec
puts ("Start: " + ustart.to_s + " usecs")
puts ("End: " + uend.to_s + " usecs")
puts ("diff: " + ((uend - ustart)/1000.0).to_s + " msecs")

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:50:36Z

Washao: /* Java vs. Ruby Thread Efficiency */

= Introduction =
A thread is a basic unit of CPU utilization. A traditional process has a single thread of control. Many modern operating systems provide features enabling a process to contain multiple threads of control. If the process has multiple threads of control, it can do more than one task at a time, such as, displaying graphics and reading keystrokes. Threads are used mainly to run asynchronous tasks and pass the application’s tasks to an executor. They are useful because they reduce the overall time of execution of programs. All threads belonging to the same process share its code section, data section and other operating system resources, such as open files and signals. Thus multithreading is more efficient than having parallel processes running for the same program, which require a huge overhead.

=Multi-threaded Programming=
Multithreading support for single processors works by giving each of the threads a “time slice” of the CPU, similar to the parallel execution of processes. On multi-core machines, different threads can run on the different processors and the threads truly run simultaneously. Support for threads may be provided at either the user level, for user or green threads, or by the kernel, for kernel or native threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

==Multi-threading Models==
There are three common multithreading models

===One-to-One===
This model maps each user-thread to a kernel thread. It provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors. The main disadvantage of this model is the overhead of creating each kernel thread for each user thread. This burdens the performance of an application and limits the number of threads supported by the system.

===Many-to-One===
This model maps many user-level threads to one kernel thread. It is the model used by green threads. Green threads are scheduled by a Virtual Machine instead of natively by the OS. They emulate multithreaded environments without relying on any native OS capabilities. These user-level threads are lightweight and very efficient. They are an easy way to achieve parallelism in a program. An application can have as many user-level threads as it needs, but true concurrency is not achieved because the kernel can schedule only one thread at a time. The developers can create as many user threads as necessary. However, there are two main disadvantages:
1) If a thread makes a blocking system call, the entire process will block.
2) If you are running on a multi-core machine, the multiple threads are unable to run in parallel.

===Many-to-Many===
This model multiplexes many user-level threads to a smaller or equal number of kernel threads. This model has the best of both worlds. Developers can create as many user threads as they need. When a user thread performs a blocking system call, the kernel can schedule another thread for execution and the kernel threads can run in parallel on multi-core systems.

==Benefits of Multi-threading==
===Resource sharing===
Memory, code and process resource sharing - allocating memory and resources for process creation is costly and time consuming. It is more economical to create threads than new processes. Applications can benefit by having several different threads of activity within the same address space.

===Responsiveness===
Multithreading an interactive application may allow a program to continue running, even if part of it is blocked doing IO or performing a lengthy operation, thereby increasing responsiveness to the user. A web browser might have one thread display images or text while another thread retrieves data from the network. A busy web server may have many clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

==Potential Problems of Multi-threading==
Many threaded programs have shared resources that must be accessed by more than one thread. These programs must implement a form of mutual exclusion to ensure that only one of the threads can access the resource at a time. These shared resources must execute in code called critical sections. These critical sections must be protected by either hardware or software means.

=Java Threads=
The Java programming language has a thread library for creating and managing threads at the user-level. The Java virtual machine (JVM) manages the mapping of the user threads to the operating system kernel threads. The particular mapping model that is used depends on the operating system on which the Java program is running. Java’s Thread Scheduler monitors all the threads running in Java programs. It decides which threads to run at any given time and when to switch between threads to run based on the thread’s priority with higher running threads running before lower priority threads. The Java scheduler uses either preemptive or non-preemptive scheduling based on the operating system on which it is running. With preemptive scheduling, each thread is given a constant period of time to run, after which time the thread will be suspended() to allow the next thread to resume() running. With non-preemptive scheduling, the running thread is allowed to run until the thread completes or until it issues a yield() to allow other threads to run while it waits for some other processing to occur.
A Java thread can be created either by having your Java class extend the Java Thread class or by having your Java class implement the Runnable interface and coding a run() method. The two options are shown in Figures 1 and 2. The preferred method for creating a thread is by implementing the Runnable interface. It is more flexible and useful in complex applications. Java does not support multiple inheritance, but a class may implement multiple interfaces. By using the interface method, the Client class is open to inherit another class, if the need arose in the future.

'''Figure 1: Client Extends Thread Class'''

public class Client extends Thread {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {
public static void main(String args[]){
Thread runner = new Client();
runner.start();
System.out.println(“Server thread”);
}
}

'''Figure 2: Client Implements Runnable Interface'''

public class Client implements Runnable {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {

public static void main(String args[]) {
Thread runner = new Thread(new Client());
runner.start();
System.out.println(“Server thread”);
}
}

If the main Java thread wants to wait for any threads it creates to finish their run() method, the thread method join() can be executed. The join() method is useful in situations where the creating thread can continue only after a worker thread has completed. Java threads can be asynchronously terminated using the stop() method. However, this method has been deprecated and its used is discouraged. The preferred cancellation technique is to have the target thread periodically check whether it should terminate by using the interrupt() method.

==States of Java Threads==
===New===
A thread is in this state when the thread object is first created with the new() method.
===Runnable===
Calling the start() method allocates memory for the new thread in the JVM and calls the run() method for the thread object.
===Blocked===
A thread becomes blocked if it performs a blocking statement, such as doing I/O or if it invokes a sleep() method.
===Dead===
A thread moves to the dead state when its run() method terminates.

==Mutual Exclusion==
The Java language implements mutual exclusion in a couple of ways. There exists a MutualExclusion interface. The Client class can implement this interface and code the methods, enteringCriticalSection() and leavingCriticalSection(), as shown in Figure 3. The yield() method tells the Thread Scheduler to allow another thread to run.

'''Figure 3: Client Implements MutualExclusion Interface'''

public class Client implements MutualExclusion{

public Client(){
flag0 = false; flag1 = false; turn = TURN_0;
}

public void enteringCriticalSection(int t) {
int other = 1 - t;

if (t == 0) {
flag0 = true; turn = other;
while ((flag1 == true) && (turn == other))
Thread.yield();
} else {
flag1 = true; turn = other;
while ((flag0 == true) && (turn == other))
Thread.yield();
}
}

public void leavingCriticalSection(int t) {
if(t == 0) flag0 = false;
else flag1 = false;
}
private volatile int turn, boolean flag0, flag1;
}

An alternative method of handling mutual exclusion is to code a synchronization tool called a semaphore. A semaphore is variable that is accessed only through two standard operations: acquire() and release(). The semaphore is acquired, then the critical section of an object is entered and after the critical code completes, the semaphore is released. An example of this code is in Figure 4.

'''Figure 4: Client Has Semaphore'''

public class Client implements Runnable {

public Client (Semaphore sem) {
this.sem = sem;
}

public void run() {
sem.acquire();
System.out.println("Entering critical section");
SleepUtilities.nap(3);
System.out.println("Leaving critical section");
sem.release();
}
private Semaphore sem;
}

=Ruby Threads=
At the present time the Ruby programming language just supports green threads. These are totally implemented within the Ruby interpreter. The threads, as well as the thread scheduler run on the same single operating system thread. Ruby can support thread methods, such as stop() and kill(), that are not advised for kernel threads. However, Ruby threads suffer from the drawbacks of non-native threads. They can only run on one processor in a multiprocessor environment. It is possible for a single thread to cause the whole process to deadlock, if poorly designed. The worse problem with Ruby threads is with I/O, especially network access, since it has the potential to block a process for a long time. This problem is solvable by using non-blocking I/O. However, one problem that is not solvable using non-blocking I/O, is the DNS lookup system call. Ruby solves this problem with their resolv library, which was written specifically to address the threading issue with the standard OS DNA lookup mechanism. See Figure 5 for an example of the code that handles this issue. Despite some of the green thread concerns, for most situations, the benefits of efficiency can far outweigh the disadvantages.

'''Figure 5: Ruby DNS Lookup Implementation'''

require ‘socket’
require ‘resolv-replace’
count = 0
Thread.critical = true
thread = Thread.new { Thread.pass; loop { count += 1; } } IPSocket.getaddress(www.ruby-lang.org)
count

A Ruby thread is created using Thread.new() {block}. The arguments given in the new() method are passed to the block code that the thread executes. See Figure 6 for an example of creating a Ruby thread. The Ruby pass() method is analogous to the Java yield() method. It tells the thread scheduler to pass execution to another thread. Ruby has a join() method that performs the same functionality as the Java join(). There are run() and wakeup() methods that wake up a sleeping threads, either giving it control or indicating that it is ready to be scheduled.

'''Figure 6: Creating Ruby Threads'''

threads = []
4.times do |number|
threads << Thread.new(number) do |i|
print “#{i}\n”
end
end
threads.each { |t| t.join }

==States of Ruby Threads==
===Run===
The thread is executing.
===Sleep===
The thread is sleeping or waiting on I/O.
===Aborting===
The thread is aborting (has been killed).
===False===
The thread has terminated normally.
===Nil===
The thread has terminated with an exception.

==Mutual Exclusion==
The best way to handle mutual exclusion in Ruby is with the Monitor class. A monitor has a synchronization() method that prevent access to a resource by another thread while one is execution in that method. Figure 7 shows an example of how this can be used.

'''Figure 7: Ruby Monitor'''

require 'monitor'
class Counter < Monitor
attr_reader :count

def initialize
@count = 0
super
end

def tick
synchronize do
@count += 1
end
end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join; t2.join
c.count

=Java vs Ruby Threads=
Java thread initialization is more involved than Ruby thread initialization. Ruby threads also have the advantage of a “quick and dirty” thread creation, since it only takes couple of lines of code. A Ruby thread shares all global, instance and local variables that are in existence at the time the thread starts. A Java thread can share these variables, as well, depending on how the thread was created. If the client thread class uses inheritance, any variables needed are passed along when creating the thread. If the thread is created through the interface, the variables can be shared as long as the class has been initialized and the variables in use.

Ruby’s green threads are completely portable, as they don’t rely on the OS. But, on a multi-core processor, native thread implementations can assign work to multiple processors while green threads cannot. In this environment native threads have a huge advantage as more work is done by the native threads.

==Java and Ruby Methods Comparison==

'''Table 1 lists thread actions and Java and Ruby’s equivalent methods of achieving them.'''

[[Image:java table1.jpg]]

'''Table 2 lists thread actions available in Java, but Ruby doesn’t have a method for the action.'''

[[Image:java table2.jpg]]

'''Table 3 lists thread actions available in Ruby, but Java doesn’t have a method for the action.'''

[[Image:java table3.jpg]]

There are many similarities between the Java and Ruby Thread classes, as shown with the equivalent methods in Table 1. But, as you can see, there are also many methods in Java that Ruby doesn't support and vice versa. Some methods like activeCount(), where it returns the number of active threads, are trivial, but there is a group of methods existing in both Java and Ruby that the other doesn't support. For Java, it is exception handling with getting/setting exceptions, while in Ruby, it is more thread control. Ruby has exception methods, but they are geared more toward events prior to the exception, like making sure all threads abort when exception starts and firing an exception to destroy threads. Java is more about setting the exceptions and getting them to change accordingly. So the Java Thread class has a little bit more exception handling than Ruby.

Ruby has more thread control for the programmer such as pausing, terminating, aborting and resuming threads. Java did have these functions, but they all have been deprecated because, although they give the user more control, they also can cause deadlock problems. So it is a tradeoff between more thread control and less chance for deadlocks to happen. Java does use interrupt to "pause" the thread as opposed to actually pausing the thread as in Ruby. Also, Java threads "sleep" differently than Ruby threads. Java sleeps are timed, while Ruby's sleep just stops the thread indefinitely, until it gets woken up by "thr.wakeup". As you can see Ruby's thread methods are more flexible, but potentially dangerous than Java’s.

Basically, Java and Ruby both have similar thread functionalities. In some respects, Java is simpler by reducing user error, while Ruby gives the programmer more power and perhaps more headaches. If user wants more control, then Ruby threading is great, but for simplicity Java is better. The main distinction between Ruby threads and Java threads are that currently Ruby just supports green threads (as did Java 1.1) and Java has support for kernel threads. Currently, there is no clear “winner” between native and green threads in a uni-processor system, but Java threads definitely have the edge over Ruby in a multi-processor environment.
Ruby is moving from green threads to kernel threads in Ruby 1.9 or 2.0, which are still development releases. YARV has been integrated as the new Ruby VM. YARV will give Ruby kernel thread support. Detailed discussions of this change are at the following links:
http://www.infoq.com/news/2007/05/ruby-threading-futures
http://expressica.com/2008/04/26/new-in-ruby-19-threads/

==Java vs. Ruby Thread Efficiency==
In order to test the efficiency of Java and Ruby threads a program was written in each language that reads in the contents of five different text files and searches for a given word in each and counts each occurrence of the word. This count is then added to a total count for all five files. Each file is passed to its own thread to run. The main thread has the total count, which is updated using mutual exclusion techniques in each language. The times it took each to run depended on the size of the files. The results are recorded in Table 4. With very small files, the Ruby code ran twice as fast of the Java. With the medium sized files the Java ran twice as fast as the Ruby code. With the larger files, the Java code ran three times faster. Certainly, the Java threads outperform the Ruby threads with I/O intensive code. The Java code is in Figure 8 and the Ruby code is in Figure 9.

'''Figure 8: Java Word Counts Code'''
public class WordCounts {
protected static int wordCount;

private class Semaphore {
private int mutex;

public Semaphore () {
mutex = 1;
}

public synchronized void acquire() throws InterruptedException {
while (mutex == 0) {
wait();
}
mutex--;
}
public synchronized void release() {
mutex++;
notifyAll();
}
}

private class WordCountsThread implements Runnable {
private String word;
private String file;
private int count;
private Semaphore total;

public WordCountsThread (String word, String file, Semaphore total) {
this.word = word;
this.file = file;
this.total = total;
count = 0;
}

public void run(){
readWordFile();

try {
total.acquire();
wordCount = wordCount + count;
total.release();
} catch (InterruptedException e) {
System.out.println (e);
}
}

private void readWordFile (){
} // end method
} //end inner class: WordCountThread

public WordCounts (String searchWord, String [] files) {
int numFiles = files.length;
Semaphore total = new Semaphore();
Thread [] threads = new Thread [numFiles];

for (int i = 0; i < numFiles; i++ ) {
threads[i] = new Thread (new WordCountsThread (searchWord,files[i], total));
}

for (int j = 0; j < numFiles; j++ ) {
threads[j].start();
}

try {
for (int i = 0; i < numFiles; i++ ) {
threads[i].join();
}
} catch (InterruptedException e) {
System.out.println (e);
}
}

public void displayTotal (String searchWord) {
System.out.println ("There are " + wordCount +
" total occurrences of " + searchWord);
}

public static void main (String [] args) {
String [] files;
files = new String [5];
files [0] = "Player.java";
files [1] = "KingMove.java";
files [2] = "NodeDeque.java";
files [3] = "Position.java";
files [4] = "DoubleDigest.java";
String searchWord = "public";
long time = System.currentTimeMillis (), time_prev = time;
WordCounts wc = new WordCounts (searchWord, files);
wc.displayTotal (searchWord);
time = System.currentTimeMillis ();
System.out.println ("Diff " + (time - time_prev) + " msecs");
System.exit(0);
}
}

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:40:40Z

Washao:

= Introduction =
A thread is a basic unit of CPU utilization. A traditional process has a single thread of control. Many modern operating systems provide features enabling a process to contain multiple threads of control. If the process has multiple threads of control, it can do more than one task at a time, such as, displaying graphics and reading keystrokes. Threads are used mainly to run asynchronous tasks and pass the application’s tasks to an executor. They are useful because they reduce the overall time of execution of programs. All threads belonging to the same process share its code section, data section and other operating system resources, such as open files and signals. Thus multithreading is more efficient than having parallel processes running for the same program, which require a huge overhead.

=Multi-threaded Programming=
Multithreading support for single processors works by giving each of the threads a “time slice” of the CPU, similar to the parallel execution of processes. On multi-core machines, different threads can run on the different processors and the threads truly run simultaneously. Support for threads may be provided at either the user level, for user or green threads, or by the kernel, for kernel or native threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

==Multi-threading Models==
There are three common multithreading models

===One-to-One===
This model maps each user-thread to a kernel thread. It provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors. The main disadvantage of this model is the overhead of creating each kernel thread for each user thread. This burdens the performance of an application and limits the number of threads supported by the system.

===Many-to-One===
This model maps many user-level threads to one kernel thread. It is the model used by green threads. Green threads are scheduled by a Virtual Machine instead of natively by the OS. They emulate multithreaded environments without relying on any native OS capabilities. These user-level threads are lightweight and very efficient. They are an easy way to achieve parallelism in a program. An application can have as many user-level threads as it needs, but true concurrency is not achieved because the kernel can schedule only one thread at a time. The developers can create as many user threads as necessary. However, there are two main disadvantages:
1) If a thread makes a blocking system call, the entire process will block.
2) If you are running on a multi-core machine, the multiple threads are unable to run in parallel.

===Many-to-Many===
This model multiplexes many user-level threads to a smaller or equal number of kernel threads. This model has the best of both worlds. Developers can create as many user threads as they need. When a user thread performs a blocking system call, the kernel can schedule another thread for execution and the kernel threads can run in parallel on multi-core systems.

==Benefits of Multi-threading==
===Resource sharing===
Memory, code and process resource sharing - allocating memory and resources for process creation is costly and time consuming. It is more economical to create threads than new processes. Applications can benefit by having several different threads of activity within the same address space.

===Responsiveness===
Multithreading an interactive application may allow a program to continue running, even if part of it is blocked doing IO or performing a lengthy operation, thereby increasing responsiveness to the user. A web browser might have one thread display images or text while another thread retrieves data from the network. A busy web server may have many clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

==Potential Problems of Multi-threading==
Many threaded programs have shared resources that must be accessed by more than one thread. These programs must implement a form of mutual exclusion to ensure that only one of the threads can access the resource at a time. These shared resources must execute in code called critical sections. These critical sections must be protected by either hardware or software means.

=Java Threads=
The Java programming language has a thread library for creating and managing threads at the user-level. The Java virtual machine (JVM) manages the mapping of the user threads to the operating system kernel threads. The particular mapping model that is used depends on the operating system on which the Java program is running. Java’s Thread Scheduler monitors all the threads running in Java programs. It decides which threads to run at any given time and when to switch between threads to run based on the thread’s priority with higher running threads running before lower priority threads. The Java scheduler uses either preemptive or non-preemptive scheduling based on the operating system on which it is running. With preemptive scheduling, each thread is given a constant period of time to run, after which time the thread will be suspended() to allow the next thread to resume() running. With non-preemptive scheduling, the running thread is allowed to run until the thread completes or until it issues a yield() to allow other threads to run while it waits for some other processing to occur.
A Java thread can be created either by having your Java class extend the Java Thread class or by having your Java class implement the Runnable interface and coding a run() method. The two options are shown in Figures 1 and 2. The preferred method for creating a thread is by implementing the Runnable interface. It is more flexible and useful in complex applications. Java does not support multiple inheritance, but a class may implement multiple interfaces. By using the interface method, the Client class is open to inherit another class, if the need arose in the future.

'''Figure 1: Client Extends Thread Class'''

public class Client extends Thread {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {
public static void main(String args[]){
Thread runner = new Client();
runner.start();
System.out.println(“Server thread”);
}
}

'''Figure 2: Client Implements Runnable Interface'''

public class Client implements Runnable {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {

public static void main(String args[]) {
Thread runner = new Thread(new Client());
runner.start();
System.out.println(“Server thread”);
}
}

If the main Java thread wants to wait for any threads it creates to finish their run() method, the thread method join() can be executed. The join() method is useful in situations where the creating thread can continue only after a worker thread has completed. Java threads can be asynchronously terminated using the stop() method. However, this method has been deprecated and its used is discouraged. The preferred cancellation technique is to have the target thread periodically check whether it should terminate by using the interrupt() method.

==States of Java Threads==
===New===
A thread is in this state when the thread object is first created with the new() method.
===Runnable===
Calling the start() method allocates memory for the new thread in the JVM and calls the run() method for the thread object.
===Blocked===
A thread becomes blocked if it performs a blocking statement, such as doing I/O or if it invokes a sleep() method.
===Dead===
A thread moves to the dead state when its run() method terminates.

==Mutual Exclusion==
The Java language implements mutual exclusion in a couple of ways. There exists a MutualExclusion interface. The Client class can implement this interface and code the methods, enteringCriticalSection() and leavingCriticalSection(), as shown in Figure 3. The yield() method tells the Thread Scheduler to allow another thread to run.

'''Figure 3: Client Implements MutualExclusion Interface'''

public class Client implements MutualExclusion{

public Client(){
flag0 = false; flag1 = false; turn = TURN_0;
}

public void enteringCriticalSection(int t) {
int other = 1 - t;

if (t == 0) {
flag0 = true; turn = other;
while ((flag1 == true) && (turn == other))
Thread.yield();
} else {
flag1 = true; turn = other;
while ((flag0 == true) && (turn == other))
Thread.yield();
}
}

public void leavingCriticalSection(int t) {
if(t == 0) flag0 = false;
else flag1 = false;
}
private volatile int turn, boolean flag0, flag1;
}

An alternative method of handling mutual exclusion is to code a synchronization tool called a semaphore. A semaphore is variable that is accessed only through two standard operations: acquire() and release(). The semaphore is acquired, then the critical section of an object is entered and after the critical code completes, the semaphore is released. An example of this code is in Figure 4.

'''Figure 4: Client Has Semaphore'''

public class Client implements Runnable {

public Client (Semaphore sem) {
this.sem = sem;
}

public void run() {
sem.acquire();
System.out.println("Entering critical section");
SleepUtilities.nap(3);
System.out.println("Leaving critical section");
sem.release();
}
private Semaphore sem;
}

=Ruby Threads=
At the present time the Ruby programming language just supports green threads. These are totally implemented within the Ruby interpreter. The threads, as well as the thread scheduler run on the same single operating system thread. Ruby can support thread methods, such as stop() and kill(), that are not advised for kernel threads. However, Ruby threads suffer from the drawbacks of non-native threads. They can only run on one processor in a multiprocessor environment. It is possible for a single thread to cause the whole process to deadlock, if poorly designed. The worse problem with Ruby threads is with I/O, especially network access, since it has the potential to block a process for a long time. This problem is solvable by using non-blocking I/O. However, one problem that is not solvable using non-blocking I/O, is the DNS lookup system call. Ruby solves this problem with their resolv library, which was written specifically to address the threading issue with the standard OS DNA lookup mechanism. See Figure 5 for an example of the code that handles this issue. Despite some of the green thread concerns, for most situations, the benefits of efficiency can far outweigh the disadvantages.

'''Figure 5: Ruby DNS Lookup Implementation'''

require ‘socket’
require ‘resolv-replace’
count = 0
Thread.critical = true
thread = Thread.new { Thread.pass; loop { count += 1; } } IPSocket.getaddress(www.ruby-lang.org)
count

A Ruby thread is created using Thread.new() {block}. The arguments given in the new() method are passed to the block code that the thread executes. See Figure 6 for an example of creating a Ruby thread. The Ruby pass() method is analogous to the Java yield() method. It tells the thread scheduler to pass execution to another thread. Ruby has a join() method that performs the same functionality as the Java join(). There are run() and wakeup() methods that wake up a sleeping threads, either giving it control or indicating that it is ready to be scheduled.

'''Figure 6: Creating Ruby Threads'''

threads = []
4.times do |number|
threads << Thread.new(number) do |i|
print “#{i}\n”
end
end
threads.each { |t| t.join }

==States of Ruby Threads==
===Run===
The thread is executing.
===Sleep===
The thread is sleeping or waiting on I/O.
===Aborting===
The thread is aborting (has been killed).
===False===
The thread has terminated normally.
===Nil===
The thread has terminated with an exception.

==Mutual Exclusion==
The best way to handle mutual exclusion in Ruby is with the Monitor class. A monitor has a synchronization() method that prevent access to a resource by another thread while one is execution in that method. Figure 7 shows an example of how this can be used.

'''Figure 7: Ruby Monitor'''

require 'monitor'
class Counter < Monitor
attr_reader :count

def initialize
@count = 0
super
end

def tick
synchronize do
@count += 1
end
end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join; t2.join
c.count

=Java vs Ruby Threads=
Java thread initialization is more involved than Ruby thread initialization. Ruby threads also have the advantage of a “quick and dirty” thread creation, since it only takes couple of lines of code. A Ruby thread shares all global, instance and local variables that are in existence at the time the thread starts. A Java thread can share these variables, as well, depending on how the thread was created. If the client thread class uses inheritance, any variables needed are passed along when creating the thread. If the thread is created through the interface, the variables can be shared as long as the class has been initialized and the variables in use.

Ruby’s green threads are completely portable, as they don’t rely on the OS. But, on a multi-core processor, native thread implementations can assign work to multiple processors while green threads cannot. In this environment native threads have a huge advantage as more work is done by the native threads.

==Java and Ruby Methods Comparison==

'''Table 1 lists thread actions and Java and Ruby’s equivalent methods of achieving them.'''

[[Image:java table1.jpg]]

'''Table 2 lists thread actions available in Java, but Ruby doesn’t have a method for the action.'''

[[Image:java table2.jpg]]

'''Table 3 lists thread actions available in Ruby, but Java doesn’t have a method for the action.'''

[[Image:java table3.jpg]]

There are many similarities between the Java and Ruby Thread classes, as shown with the equivalent methods in Table 1. But, as you can see, there are also many methods in Java that Ruby doesn't support and vice versa. Some methods like activeCount(), where it returns the number of active threads, are trivial, but there is a group of methods existing in both Java and Ruby that the other doesn't support. For Java, it is exception handling with getting/setting exceptions, while in Ruby, it is more thread control. Ruby has exception methods, but they are geared more toward events prior to the exception, like making sure all threads abort when exception starts and firing an exception to destroy threads. Java is more about setting the exceptions and getting them to change accordingly. So the Java Thread class has a little bit more exception handling than Ruby.

Ruby has more thread control for the programmer such as pausing, terminating, aborting and resuming threads. Java did have these functions, but they all have been deprecated because, although they give the user more control, they also can cause deadlock problems. So it is a tradeoff between more thread control and less chance for deadlocks to happen. Java does use interrupt to "pause" the thread as opposed to actually pausing the thread as in Ruby. Also, Java threads "sleep" differently than Ruby threads. Java sleeps are timed, while Ruby's sleep just stops the thread indefinitely, until it gets woken up by "thr.wakeup". As you can see Ruby's thread methods are more flexible, but potentially dangerous than Java’s.

Basically, Java and Ruby both have similar thread functionalities. In some respects, Java is simpler by reducing user error, while Ruby gives the programmer more power and perhaps more headaches. If user wants more control, then Ruby threading is great, but for simplicity Java is better. The main distinction between Ruby threads and Java threads are that currently Ruby just supports green threads (as did Java 1.1) and Java has support for kernel threads. Currently, there is no clear “winner” between native and green threads in a uni-processor system, but Java threads definitely have the edge over Ruby in a multi-processor environment.
Ruby is moving from green threads to kernel threads in Ruby 1.9 or 2.0, which are still development releases. YARV has been integrated as the new Ruby VM. YARV will give Ruby kernel thread support. Detailed discussions of this change are at the following links:
http://www.infoq.com/news/2007/05/ruby-threading-futures
http://expressica.com/2008/04/26/new-in-ruby-19-threads/

==Java vs. Ruby Thread Efficiency==
In order to test the efficiency of Java and Ruby threads a program was written in each language that reads in the contents of five different text files and searches for a given word in each and counts each occurrence of the word. This count is then added to a total count for all five files. Each file is passed to its own thread to run. The main thread has the total count, which is updated using mutual exclusion techniques in each language. The times it took each to run depended on the size of the files. The results are recorded in Table 4. With very small files, the Ruby code ran twice as fast of the Java. With the medium sized files the Java ran twice as fast as the Ruby code. With the larger files, the Java code ran three times faster. Certainly, the Java threads outperform the Ruby threads with I/O intensive code. The Java code is in Figure 8 and the Ruby code is in Figure 9.

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:39:19Z

Washao:

= Introduction =
A thread is a basic unit of CPU utilization. A traditional process has a single thread of control. Many modern operating systems provide features enabling a process to contain multiple threads of control. If the process has multiple threads of control, it can do more than one task at a time, such as, displaying graphics and reading keystrokes. Threads are used mainly to run asynchronous tasks and pass the application’s tasks to an executor. They are useful because they reduce the overall time of execution of programs. All threads belonging to the same process share its code section, data section and other operating system resources, such as open files and signals. Thus multithreading is more efficient than having parallel processes running for the same program, which require a huge overhead.

=Multi-threaded programming=
Multithreading support for single processors works by giving each of the threads a “time slice” of the CPU, similar to the parallel execution of processes. On multi-core machines, different threads can run on the different processors and the threads truly run simultaneously. Support for threads may be provided at either the user level, for user or green threads, or by the kernel, for kernel or native threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

==Multi-threading models==
There are three common multithreading models

===One-to-one===
This model maps each user-thread to a kernel thread. It provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors. The main disadvantage of this model is the overhead of creating each kernel thread for each user thread. This burdens the performance of an application and limits the number of threads supported by the system.

===Many-to-one===
This model maps many user-level threads to one kernel thread. It is the model used by green threads. Green threads are scheduled by a Virtual Machine instead of natively by the OS. They emulate multithreaded environments without relying on any native OS capabilities. These user-level threads are lightweight and very efficient. They are an easy way to achieve parallelism in a program. An application can have as many user-level threads as it needs, but true concurrency is not achieved because the kernel can schedule only one thread at a time. The developers can create as many user threads as necessary. However, there are two main disadvantages:
1) If a thread makes a blocking system call, the entire process will block.
2) If you are running on a multi-core machine, the multiple threads are unable to run in parallel.

===Many-to-Many===
This model multiplexes many user-level threads to a smaller or equal number of kernel threads. This model has the best of both worlds. Developers can create as many user threads as they need. When a user thread performs a blocking system call, the kernel can schedule another thread for execution and the kernel threads can run in parallel on multi-core systems.

==Benefits of multi-threading==
===Resource sharing===
Memory, code and process resource sharing - allocating memory and resources for process creation is costly and time consuming. It is more economical to create threads than new processes. Applications can benefit by having several different threads of activity within the same address space.

===Responsiveness===
Multithreading an interactive application may allow a program to continue running, even if part of it is blocked doing IO or performing a lengthy operation, thereby increasing responsiveness to the user. A web browser might have one thread display images or text while another thread retrieves data from the network. A busy web server may have many clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

==Potential problems of multi-threading==
Many threaded programs have shared resources that must be accessed by more than one thread. These programs must implement a form of mutual exclusion to ensure that only one of the threads can access the resource at a time. These shared resources must execute in code called critical sections. These critical sections must be protected by either hardware or software means.

=Java threads=
The Java programming language has a thread library for creating and managing threads at the user-level. The Java virtual machine (JVM) manages the mapping of the user threads to the operating system kernel threads. The particular mapping model that is used depends on the operating system on which the Java program is running. Java’s Thread Scheduler monitors all the threads running in Java programs. It decides which threads to run at any given time and when to switch between threads to run based on the thread’s priority with higher running threads running before lower priority threads. The Java scheduler uses either preemptive or non-preemptive scheduling based on the operating system on which it is running. With preemptive scheduling, each thread is given a constant period of time to run, after which time the thread will be suspended() to allow the next thread to resume() running. With non-preemptive scheduling, the running thread is allowed to run until the thread completes or until it issues a yield() to allow other threads to run while it waits for some other processing to occur.
A Java thread can be created either by having your Java class extend the Java Thread class or by having your Java class implement the Runnable interface and coding a run() method. The two options are shown in Figures 1 and 2. The preferred method for creating a thread is by implementing the Runnable interface. It is more flexible and useful in complex applications. Java does not support multiple inheritance, but a class may implement multiple interfaces. By using the interface method, the Client class is open to inherit another class, if the need arose in the future.

'''Figure 1: Client Extends Thread Class'''

public class Client extends Thread {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {
public static void main(String args[]){
Thread runner = new Client();
runner.start();
System.out.println(“Server thread”);
}
}

'''Figure 2: Client Implements Runnable Interface'''

public class Client implements Runnable {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {

public static void main(String args[]) {
Thread runner = new Thread(new Client());
runner.start();
System.out.println(“Server thread”);
}
}

If the main Java thread wants to wait for any threads it creates to finish their run() method, the thread method join() can be executed. The join() method is useful in situations where the creating thread can continue only after a worker thread has completed. Java threads can be asynchronously terminated using the stop() method. However, this method has been deprecated and its used is discouraged. The preferred cancellation technique is to have the target thread periodically check whether it should terminate by using the interrupt() method.

==States of Java threads==
===New===
A thread is in this state when the thread object is first created with the new() method.
===Runnable===
Calling the start() method allocates memory for the new thread in the JVM and calls the run() method for the thread object.
===Blocked===
A thread becomes blocked if it performs a blocking statement, such as doing I/O or if it invokes a sleep() method.
===Dead===
A thread moves to the dead state when its run() method terminates.

==Mutual exclusion==
The Java language implements mutual exclusion in a couple of ways. There exists a MutualExclusion interface. The Client class can implement this interface and code the methods, enteringCriticalSection() and leavingCriticalSection(), as shown in Figure 3. The yield() method tells the Thread Scheduler to allow another thread to run.

'''Figure 3: Client Implements MutualExclusion Interface'''

public class Client implements MutualExclusion{

public Client(){
flag0 = false; flag1 = false; turn = TURN_0;
}

public void enteringCriticalSection(int t) {
int other = 1 - t;

if (t == 0) {
flag0 = true; turn = other;
while ((flag1 == true) && (turn == other))
Thread.yield();
} else {
flag1 = true; turn = other;
while ((flag0 == true) && (turn == other))
Thread.yield();
}
}

public void leavingCriticalSection(int t) {
if(t == 0) flag0 = false;
else flag1 = false;
}
private volatile int turn, boolean flag0, flag1;
}

An alternative method of handling mutual exclusion is to code a synchronization tool called a semaphore. A semaphore is variable that is accessed only through two standard operations: acquire() and release(). The semaphore is acquired, then the critical section of an object is entered and after the critical code completes, the semaphore is released. An example of this code is in Figure 4.

'''Figure 4: Client Has Semaphore'''

public class Client implements Runnable {

public Client (Semaphore sem) {
this.sem = sem;
}

public void run() {
sem.acquire();
System.out.println("Entering critical section");
SleepUtilities.nap(3);
System.out.println("Leaving critical section");
sem.release();
}
private Semaphore sem;
}

=Ruby threads=
At the present time the Ruby programming language just supports green threads. These are totally implemented within the Ruby interpreter. The threads, as well as the thread scheduler run on the same single operating system thread. Ruby can support thread methods, such as stop() and kill(), that are not advised for kernel threads. However, Ruby threads suffer from the drawbacks of non-native threads. They can only run on one processor in a multiprocessor environment. It is possible for a single thread to cause the whole process to deadlock, if poorly designed. The worse problem with Ruby threads is with I/O, especially network access, since it has the potential to block a process for a long time. This problem is solvable by using non-blocking I/O. However, one problem that is not solvable using non-blocking I/O, is the DNS lookup system call. Ruby solves this problem with their resolv library, which was written specifically to address the threading issue with the standard OS DNA lookup mechanism. See Figure 5 for an example of the code that handles this issue. Despite some of the green thread concerns, for most situations, the benefits of efficiency can far outweigh the disadvantages.

'''Figure 5: Ruby DNS Lookup Implementation'''

require ‘socket’
require ‘resolv-replace’
count = 0
Thread.critical = true
thread = Thread.new { Thread.pass; loop { count += 1; } } IPSocket.getaddress(www.ruby-lang.org)
count

A Ruby thread is created using Thread.new() {block}. The arguments given in the new() method are passed to the block code that the thread executes. See Figure 6 for an example of creating a Ruby thread. The Ruby pass() method is analogous to the Java yield() method. It tells the thread scheduler to pass execution to another thread. Ruby has a join() method that performs the same functionality as the Java join(). There are run() and wakeup() methods that wake up a sleeping threads, either giving it control or indicating that it is ready to be scheduled.

'''Figure 6: Creating Ruby Threads'''

threads = []
4.times do |number|
threads << Thread.new(number) do |i|
print “#{i}\n”
end
end
threads.each { |t| t.join }

==States of Ruby threads==
===Run===
The thread is executing.
===Sleep===
The thread is sleeping or waiting on I/O.
===Aborting===
The thread is aborting (has been killed).
===False===
The thread has terminated normally.
===Nil===
The thread has terminated with an exception.

==Mutual Exclusion==
The best way to handle mutual exclusion in Ruby is with the Monitor class. A monitor has a synchronization() method that prevent access to a resource by another thread while one is execution in that method. Figure 7 shows an example of how this can be used.

'''Figure 7: Ruby Monitor'''

require 'monitor'
class Counter < Monitor
attr_reader :count

def initialize
@count = 0
super
end

def tick
synchronize do
@count += 1
end
end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join; t2.join
c.count

=Java vs Ruby threads=
Java thread initialization is more involved than Ruby thread initialization. Ruby threads also have the advantage of a “quick and dirty” thread creation, since it only takes couple of lines of code. A Ruby thread shares all global, instance and local variables that are in existence at the time the thread starts. A Java thread can share these variables, as well, depending on how the thread was created. If the client thread class uses inheritance, any variables needed are passed along when creating the thread. If the thread is created through the interface, the variables can be shared as long as the class has been initialized and the variables in use.

Ruby’s green threads are completely portable, as they don’t rely on the OS. But, on a multi-core processor, native thread implementations can assign work to multiple processors while green threads cannot. In this environment native threads have a huge advantage as more work is done by the native threads.

==Java and Ruby methods comparison==

'''Table 1 lists thread actions and Java and Ruby’s equivalent methods of achieving them.'''

[[Image:java table1.jpg]]

'''Table 2 lists thread actions available in Java, but Ruby doesn’t have a method for the action.'''

[[Image:java table2.jpg]]

'''Table 3 lists thread actions available in Ruby, but Java doesn’t have a method for the action.'''

[[Image:java table3.jpg]]

There are many similarities between the Java and Ruby Thread classes, as shown with the equivalent methods in Table 1. But, as you can see, there are also many methods in Java that Ruby doesn't support and vice versa. Some methods like activeCount(), where it returns the number of active threads, are trivial, but there is a group of methods existing in both Java and Ruby that the other doesn't support. For Java, it is exception handling with getting/setting exceptions, while in Ruby, it is more thread control. Ruby has exception methods, but they are geared more toward events prior to the exception, like making sure all threads abort when exception starts and firing an exception to destroy threads. Java is more about setting the exceptions and getting them to change accordingly. So the Java Thread class has a little bit more exception handling than Ruby.

Ruby has more thread control for the programmer such as pausing, terminating, aborting and resuming threads. Java did have these functions, but they all have been deprecated because, although they give the user more control, they also can cause deadlock problems. So it is a tradeoff between more thread control and less chance for deadlocks to happen. Java does use interrupt to "pause" the thread as opposed to actually pausing the thread as in Ruby. Also, Java threads "sleep" differently than Ruby threads. Java sleeps are timed, while Ruby's sleep just stops the thread indefinitely, until it gets woken up by "thr.wakeup". As you can see Ruby's thread methods are more flexible, but potentially dangerous than Java’s.

Basically, Java and Ruby both have similar thread functionalities. In some respects, Java is simpler by reducing user error, while Ruby gives the programmer more power and perhaps more headaches. If user wants more control, then Ruby threading is great, but for simplicity Java is better. The main distinction between Ruby threads and Java threads are that currently Ruby just supports green threads (as did Java 1.1) and Java has support for kernel threads. Currently, there is no clear “winner” between native and green threads in a uni-processor system, but Java threads definitely have the edge over Ruby in a multi-processor environment.
Ruby is moving from green threads to kernel threads in Ruby 1.9 or 2.0, which are still development releases. YARV has been integrated as the new Ruby VM. YARV will give Ruby kernel thread support. Detailed discussions of this change are at the following links:
http://www.infoq.com/news/2007/05/ruby-threading-futures
http://expressica.com/2008/04/26/new-in-ruby-19-threads/

==Java vs. Ruby Thread Efficiency==
In order to test the efficiency of Java and Ruby threads a program was written in each language that reads in the contents of five different text files and searches for a given word in each and counts each occurrence of the word. This count is then added to a total count for all five files. Each file is passed to its own thread to run. The main thread has the total count, which is updated using mutual exclusion techniques in each language. The times it took each to run depended on the size of the files. The results are recorded in Table 4. With very small files, the Ruby code ran twice as fast of the Java. With the medium sized files the Java ran twice as fast as the Ruby code. With the larger files, the Java code ran three times faster. Certainly, the Java threads outperform the Ruby threads with I/O intensive code. The Java code is in Figure 8 and the Ruby code is in Figure 9.

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:38:23Z

Washao: /* Java and Ruby methods comparison */

= Introduction =
A thread is a basic unit of CPU utilization. A traditional process has a single thread of control. Many modern operating systems provide features enabling a process to contain multiple threads of control. If the process has multiple threads of control, it can do more than one task at a time, such as, displaying graphics and reading keystrokes. Threads are used mainly to run asynchronous tasks and pass the application’s tasks to an executor. They are useful because they reduce the overall time of execution of programs. All threads belonging to the same process share its code section, data section and other operating system resources, such as open files and signals. Thus multithreading is more efficient than having parallel processes running for the same program, which require a huge overhead.

=Multi-threaded programming=
Multithreading support for single processors works by giving each of the threads a “time slice” of the CPU, similar to the parallel execution of processes. On multi-core machines, different threads can run on the different processors and the threads truly run simultaneously. Support for threads may be provided at either the user level, for user or green threads, or by the kernel, for kernel or native threads. User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

==Multi-threading models==
There are three common multithreading models

===One-to-one===
This model maps each user-thread to a kernel thread. It provides more concurrency than the many-to-one model by allowing another thread to run when a thread makes a blocking system call. It also allows multiple threads to run in parallel on multiprocessors. The main disadvantage of this model is the overhead of creating each kernel thread for each user thread. This burdens the performance of an application and limits the number of threads supported by the system.

===Many-to-one===
This model maps many user-level threads to one kernel thread. It is the model used by green threads. Green threads are scheduled by a Virtual Machine instead of natively by the OS. They emulate multithreaded environments without relying on any native OS capabilities. These user-level threads are lightweight and very efficient. They are an easy way to achieve parallelism in a program. An application can have as many user-level threads as it needs, but true concurrency is not achieved because the kernel can schedule only one thread at a time. The developers can create as many user threads as necessary. However, there are two main disadvantages:
1) If a thread makes a blocking system call, the entire process will block.
2) If you are running on a multi-core machine, the multiple threads are unable to run in parallel.

===Many-to-Many===
This model multiplexes many user-level threads to a smaller or equal number of kernel threads. This model has the best of both worlds. Developers can create as many user threads as they need. When a user thread performs a blocking system call, the kernel can schedule another thread for execution and the kernel threads can run in parallel on multi-core systems.

==Benefits of multi-threading==
===Resource sharing===
Memory, code and process resource sharing - allocating memory and resources for process creation is costly and time consuming. It is more economical to create threads than new processes. Applications can benefit by having several different threads of activity within the same address space.

===Responsiveness===
Multithreading an interactive application may allow a program to continue running, even if part of it is blocked doing IO or performing a lengthy operation, thereby increasing responsiveness to the user. A web browser might have one thread display images or text while another thread retrieves data from the network. A busy web server may have many clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

==Potential problems of multi-threading==
Many threaded programs have shared resources that must be accessed by more than one thread. These programs must implement a form of mutual exclusion to ensure that only one of the threads can access the resource at a time. These shared resources must execute in code called critical sections. These critical sections must be protected by either hardware or software means.

=Java threads=
The Java programming language has a thread library for creating and managing threads at the user-level. The Java virtual machine (JVM) manages the mapping of the user threads to the operating system kernel threads. The particular mapping model that is used depends on the operating system on which the Java program is running. Java’s Thread Scheduler monitors all the threads running in Java programs. It decides which threads to run at any given time and when to switch between threads to run based on the thread’s priority with higher running threads running before lower priority threads. The Java scheduler uses either preemptive or non-preemptive scheduling based on the operating system on which it is running. With preemptive scheduling, each thread is given a constant period of time to run, after which time the thread will be suspended() to allow the next thread to resume() running. With non-preemptive scheduling, the running thread is allowed to run until the thread completes or until it issues a yield() to allow other threads to run while it waits for some other processing to occur.
A Java thread can be created either by having your Java class extend the Java Thread class or by having your Java class implement the Runnable interface and coding a run() method. The two options are shown in Figures 1 and 2. The preferred method for creating a thread is by implementing the Runnable interface. It is more flexible and useful in complex applications. Java does not support multiple inheritance, but a class may implement multiple interfaces. By using the interface method, the Client class is open to inherit another class, if the need arose in the future.

'''Figure 1: Client Extends Thread Class'''

public class Client extends Thread {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {
public static void main(String args[]){
Thread runner = new Client();
runner.start();
System.out.println(“Server thread”);
}
}

'''Figure 2: Client Implements Runnable Interface'''

public class Client implements Runnable {
public void run() {
System.out.println(“Client thread”);
}
}

public class Server {

public static void main(String args[]) {
Thread runner = new Thread(new Client());
runner.start();
System.out.println(“Server thread”);
}
}

If the main Java thread wants to wait for any threads it creates to finish their run() method, the thread method join() can be executed. The join() method is useful in situations where the creating thread can continue only after a worker thread has completed. Java threads can be asynchronously terminated using the stop() method. However, this method has been deprecated and its used is discouraged. The preferred cancellation technique is to have the target thread periodically check whether it should terminate by using the interrupt() method.

==States of Java threads==
===New===
A thread is in this state when the thread object is first created with the new() method.
===Runnable===
Calling the start() method allocates memory for the new thread in the JVM and calls the run() method for the thread object.
===Blocked===
A thread becomes blocked if it performs a blocking statement, such as doing I/O or if it invokes a sleep() method.
===Dead===
A thread moves to the dead state when its run() method terminates.

==Mutual exclusion==
The Java language implements mutual exclusion in a couple of ways. There exists a MutualExclusion interface. The Client class can implement this interface and code the methods, enteringCriticalSection() and leavingCriticalSection(), as shown in Figure 3. The yield() method tells the Thread Scheduler to allow another thread to run.

'''Figure 3: Client Implements MutualExclusion Interface'''

public class Client implements MutualExclusion{

public Client(){
flag0 = false; flag1 = false; turn = TURN_0;
}

public void enteringCriticalSection(int t) {
int other = 1 - t;

if (t == 0) {
flag0 = true; turn = other;
while ((flag1 == true) && (turn == other))
Thread.yield();
} else {
flag1 = true; turn = other;
while ((flag0 == true) && (turn == other))
Thread.yield();
}
}

public void leavingCriticalSection(int t) {
if(t == 0) flag0 = false;
else flag1 = false;
}
private volatile int turn, boolean flag0, flag1;
}

An alternative method of handling mutual exclusion is to code a synchronization tool called a semaphore. A semaphore is variable that is accessed only through two standard operations: acquire() and release(). The semaphore is acquired, then the critical section of an object is entered and after the critical code completes, the semaphore is released. An example of this code is in Figure 4.

'''Figure 4: Client Has Semaphore'''

public class Client implements Runnable {

public Client (Semaphore sem) {
this.sem = sem;
}

public void run() {
sem.acquire();
System.out.println("Entering critical section");
SleepUtilities.nap(3);
System.out.println("Leaving critical section");
sem.release();
}
private Semaphore sem;
}

=Ruby threads=
At the present time the Ruby programming language just supports green threads. These are totally implemented within the Ruby interpreter. The threads, as well as the thread scheduler run on the same single operating system thread. Ruby can support thread methods, such as stop() and kill(), that are not advised for kernel threads. However, Ruby threads suffer from the drawbacks of non-native threads. They can only run on one processor in a multiprocessor environment. It is possible for a single thread to cause the whole process to deadlock, if poorly designed. The worse problem with Ruby threads is with I/O, especially network access, since it has the potential to block a process for a long time. This problem is solvable by using non-blocking I/O. However, one problem that is not solvable using non-blocking I/O, is the DNS lookup system call. Ruby solves this problem with their resolv library, which was written specifically to address the threading issue with the standard OS DNA lookup mechanism. See Figure 5 for an example of the code that handles this issue. Despite some of the green thread concerns, for most situations, the benefits of efficiency can far outweigh the disadvantages.

'''Figure 5: Ruby DNS Lookup Implementation'''

require ‘socket’
require ‘resolv-replace’
count = 0
Thread.critical = true
thread = Thread.new { Thread.pass; loop { count += 1; } } IPSocket.getaddress(www.ruby-lang.org)
count

A Ruby thread is created using Thread.new() {block}. The arguments given in the new() method are passed to the block code that the thread executes. See Figure 6 for an example of creating a Ruby thread. The Ruby pass() method is analogous to the Java yield() method. It tells the thread scheduler to pass execution to another thread. Ruby has a join() method that performs the same functionality as the Java join(). There are run() and wakeup() methods that wake up a sleeping threads, either giving it control or indicating that it is ready to be scheduled.

'''Figure 6: Creating Ruby Threads'''

threads = []
4.times do |number|
threads << Thread.new(number) do |i|
print “#{i}\n”
end
end
threads.each { |t| t.join }

==States of Ruby threads==
===Run===
The thread is executing.
===Sleep===
The thread is sleeping or waiting on I/O.
===Aborting===
The thread is aborting (has been killed).
===False===
The thread has terminated normally.
===Nil===
The thread has terminated with an exception.

==Mutual Exclusion==
The best way to handle mutual exclusion in Ruby is with the Monitor class. A monitor has a synchronization() method that prevent access to a resource by another thread while one is execution in that method. Figure 7 shows an example of how this can be used.

'''Figure 7: Ruby Monitor'''

require 'monitor'
class Counter < Monitor
attr_reader :count

def initialize
@count = 0
super
end

def tick
synchronize do
@count += 1
end
end
end

c = Counter.new
t1 = Thread.new { 10000.times { c.tick } }
t2 = Thread.new { 10000.times { c.tick } }
t1.join; t2.join
c.count

=Java vs Ruby threads=
Java thread initialization is more involved than Ruby thread initialization. Ruby threads also have the advantage of a “quick and dirty” thread creation, since it only takes couple of lines of code. A Ruby thread shares all global, instance and local variables that are in existence at the time the thread starts. A Java thread can share these variables, as well, depending on how the thread was created. If the client thread class uses inheritance, any variables needed are passed along when creating the thread. If the thread is created through the interface, the variables can be shared as long as the class has been initialized and the variables in use.

Ruby’s green threads are completely portable, as they don’t rely on the OS. But, on a multi-core processor, native thread implementations can assign work to multiple processors while green threads cannot. In this environment native threads have a huge advantage as more work is done by the native threads.

==Java and Ruby methods comparison==

'''Table 1 lists thread actions and Java and Ruby’s equivalent methods of achieving them.'''

[[Image:java table1.jpg]]

'''Table 2 lists thread actions available in Java, but Ruby doesn’t have a method for the action.'''

[[Image:java table2.jpg]]

'''Table 3 lists thread actions available in Ruby, but Java doesn’t have a method for the action.'''

[[Image:java table3.jpg]]

There are many similarities between the Java and Ruby Thread classes, as shown with the equivalent methods in Table 1. But, as you can see, there are also many methods in Java that Ruby doesn't support and vice versa. Some methods like activeCount(), where it returns the number of active threads, are trivial, but there is a group of methods existing in both Java and Ruby that the other doesn't support. For Java, it is exception handling with getting/setting exceptions, while in Ruby, it is more thread control. Ruby has exception methods, but they are geared more toward events prior to the exception, like making sure all threads abort when exception starts and firing an exception to destroy threads. Java is more about setting the exceptions and getting them to change accordingly. So the Java Thread class has a little bit more exception handling than Ruby.

Ruby has more thread control for the programmer such as pausing, terminating, aborting and resuming threads. Java did have these functions, but they all have been deprecated because, although they give the user more control, they also can cause deadlock problems. So it is a tradeoff between more thread control and less chance for deadlocks to happen. Java does use interrupt to "pause" the thread as opposed to actually pausing the thread as in Ruby. Also, Java threads "sleep" differently than Ruby threads. Java sleeps are timed, while Ruby's sleep just stops the thread indefinitely, until it gets woken up by "thr.wakeup". As you can see Ruby's thread methods are more flexible, but potentially dangerous than Java’s.

Basically, Java and Ruby both have similar thread functionalities. In some respects, Java is simpler by reducing user error, while Ruby gives the programmer more power and perhaps more headaches. If user wants more control, then Ruby threading is great, but for simplicity Java is better. The main distinction between Ruby threads and Java threads are that currently Ruby just supports green threads (as did Java 1.1) and Java has support for kernel threads. Currently, there is no clear “winner” between native and green threads in a uni-processor system, but Java threads definitely have the edge over Ruby in a multi-processor environment.
Ruby is moving from green threads to kernel threads in Ruby 1.9 or 2.0, which are still development releases. YARV has been integrated as the new Ruby VM. YARV will give Ruby kernel thread support. Detailed discussions of this change are at the following links:
http://www.infoq.com/news/2007/05/ruby-threading-futures
http://expressica.com/2008/04/26/new-in-ruby-19-threads/

File:Java table3.jpg

2008-06-06T17:35:07Z

Washao:

File:Java table2.jpg

2008-06-06T17:34:41Z

Washao:

File:Java table1.jpg

2008-06-06T17:31:25Z

Washao:

File:Java effi.JPG

2008-06-06T17:28:12Z

Washao:

File:Java table 3.JPG

2008-06-06T17:26:48Z

Washao:

File:Java table 2.JPG

2008-06-06T17:26:36Z

Washao:

File:Java table 1.JPG

2008-06-06T17:25:49Z

Washao:

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:19:35Z

Washao:

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:10:04Z

Washao: /* Mutual exclusion */

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T17:07:15Z

Washao:

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T16:47:53Z

Washao:

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T16:36:27Z

Washao:

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T16:33:20Z

Washao: /* Introduction */

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-06T16:22:44Z

Washao:

CSC/ECE 517 Summer 2008/wiki1 4 wm

2008-06-05T14:24:22Z

Washao:

This is the placeholder for Wei And Mary's thread page