slonik AZ
12/26/2005 4:25:00 PM
Gregory,
many thanks for your reply and insightful description of general
concepts of semaphores, mutexes and monitors. As far as I understand,
Ruby implementation of monitor and mutex provide identical
functionality that in your classification would be combination of your
items 2) and 3).
Ruby Mutex is quite advanced, pure OO and even can be mixed into any
object (require "mutex_m.rb") exactly the same way as Ruby Monitor.
So, in terms of their functionality and usage they can do the same
things with the same API. Mutex#synchronize allows for control of
multiple access points the same way as Mutex#synchronize does.
--Leo--
On 12/26/05, Gregory Seidman <gsslist+ruby@anthropohedron.net> wrote:
> On Mon, Dec 26, 2005 at 11:05:25PM +0900, slonik.az@gmail.com wrote:
> } Hi Rubyists!!
> } Ruby contains two seemingly equivalents tools for thread synchronization:
> } Mutex (defined in thread.rb) and Monitor (defined in monitor.rb). They
> } both implement classic mutex and conditional variable functionality
> } and have the same API. This begs two questions:
> }
> } 1: What is the difference between Monitor and Mutex?
> design}
> } 2: Which one of the two is the preferred solution? PickAxe 1-st
> } edition covered Mutex, PickAxe 2-nd edition covers Monitor in main
> } text and Mutex in passing in library reference.
> }
> } Any opinions are highly appreciated.
>
> There are at least three (maybe only three -- it's been a long time since
> my operating systems course in college) equivalently powerful concurrency
> control primitives: mutexes, monitors, and semaphores. They are
> equivalently powerful because you can implement any one of them in terms of
> any other. The implication, then, is that you should use the primitive that
> best suits your application. Here is some guidance on where each applies
> well:
>
> 1) Semaphores involve counting, so they are typically used for controlling
> access to a limited, but plural, number of connections to some resource.
> Some good examples are audio channels or IO channels.
>
> 2) Monitors are an OO construct and work well with controlling concurrent
> access to the multiple entry points in an object. A good example might
> be a shared queue object, on which the enqueue and dequeue operations
> are protected.
>
> 3) Mutexes are the simplest primitives. They are best for protecting either
> a single entry point (i.e. a single function/method/block) or global
> data. An example might be a thread-safe printf function that prevents
> interleaved printing.
>
> } Thanks,
> } --Leo--
> --Greg
>
>
>