Re: Threads: monitors vs. primitives

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-11 14:56:28

--- In boost_at_[hidden], scleary_at_j... wrote:
> > > I am fairly sure we can design a monitor/condition interface
> > > that is no less efficient than the primitives.
> > 
> > . . .  For instance, to implement a CV on the Win32 
> > platform correctly (i.e. it's both fair and correct) requires the 
use 
> > of a mutex (or critical section), a semaphore and an event.
> 
> How would you need anything more than just an event?  Or is 
your "fair and
> correct" definition guaranteeing first-come-first-serve?

The fair part insures, if not first come first serve, that you'll at 
least not starve any waiting threads.  The problem here, though, is 
correctness.  An event based implementation is subject to the "lost 
wakeup bug".  See http://www.cs.wustl.edu/~schmidt/win32-cv-1.html 
for a good article on the issue.

The event based approach is an obvious one, since the event can be 
used in place of a CV for a lot of tasks, but they are far from 
equivalent.  The main error of contention is the requirement that an 
externam mutex will be unlocked and then relocked within the call to 
wait, which must occur in a pseudo atomic fashion.

> > . . .  What happens in two years when we find 
> > some new synchronization technique that's safer and easier to use 
> > than the monitor and all we have is the monitor type in our 
library?  
> > It's going to be harder and less efficient to model the new 
technique 
> > off of only this one synchronization object.
> 
> I think it would only be harder because you & I are used to 
mutexes, CVs,
> and semaphores.  If we were already used to monitors, I think it 
would come
> fairly naturally.  OTOH, I would prefer to add a new technique to my
> toolbox, and keep all my old tools too.  :)

A monitor can be used like a mutex, so it's not really harder in the 
kind of sense that you're taking things here.  It's just that it 
might be harder to implement in the most efficient manner.  Even when 
implemented in the most efficient manner, it's not likely to be as 
efficient as when implemented with a variety of primitives.

BTW, I'm not new to the concept of a monitor.  I've used them in the 
past.  Some of the academic research on them is new to me, but not 
their use.

William Kempf