Hi,

I'm new to threading, and am trying to understand monitor.pluse. I get the
general idea, but what does this offer that simply using a semaphore does not
offer? If you have two threads, couldn't you just immediately have one thread
in the ciritical section and have the other try to enter. It will wait until
the lock is handed back, and the lock could continue to be passed back and
forth this way. The off thread will sleep until it's its turn. How is this
different than "pulsing" a thread to a ready queue before handing a lock back?

Thanks..

-Ben

> I'm new to threading, and am trying to understand monitor.pluse. I get the
> general idea, but what does this offer that simply using a semaphore does not
> offer? If you have two threads, couldn't you just immediately have one thread
> in the ciritical section and have the other try to enter. It will wait until
> the lock is handed back, and the lock could continue to be passed back and
> forth this way. The off thread will sleep until it's its turn. How is this
> different than "pulsing" a thread to a ready queue before handing a lock back?


Technically a monitor is an object that can handle more than ore
resource at a time. Think about what would happen if a thread that is
in its critical region needs a resource locked by another thread's
semaphore and that second thread needs to enter in the critical region
too. This would handle to a deadlock. A monitor should avoid this kind
of problems.

Ben R. wrote:

> I'm new to threading, and am trying to understand monitor.pluse. I get the
> general idea, but what does this offer that simply using a semaphore does not
> offer?

A semaphore requires that you allocate a semaphore. Every object
logically has a monitor associated with it.

-- Barry

--
http://barrkel.blogspot.com/