[omniORB] Condition varaibles - follow up...

[David Riddoch]

Ole,

omni_condition::wait() implicity unlocks the mutex. In fact it is an error
to call it if the calling thread does not already hold the mutex. If your
implementation worked on Linux then that was luck.

Have a read of http://www.orl.co.uk/omniORB/doc/omnithread/omnithread.html

The section 'Synchronisation objects' explains omni_condition. The DEC SRC
report 'An Introduction to Programming with Threads' (#35) is a very good
introduction to this stuff, available at:
  http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/


David



On Thu, 21 Jan 1999, Ole Storm wrote:

> I agree that the omni_mutex_lock class is a better way to mutex-lock an
> _entire_ function, but I don't think that this has anything to do with the
> problems I experience on WinNT. The example works fine on Linux without
> using the omni_mutex_lock - remember.
> 
> Actually, mutex-locking the entire GetItem() and PutItem() functions as
> proposed will result in a dead-lock at some point. If, for instance
> GetItem() is called on an empty buffer, the call will be set to wait in the
> call to empty_buf.wait(). But since GetItem() locks on the global mutex
> variable, PutItem() is never allowed to execute --> no items will be put
> into the buffer --> the thread waiting for new items will never be signalled
> --> dead-lock.
> This was the reason for calling mutext_region.lock() _after_ the while loop
> and not before it!
> 
> 
> Thanks anyway and best regards,
> 
> 	Ole.
> 
> ---------------------------------------------------------------
> Ole Storm
> The Institute of Applied Computer Science (IFAD)
> Forskerparken 10, DK-5230 Odense M, Denmark
> Phone: +45 6315 7134, Fax: +45 6593 2999, Email: storm@ifad.dk
> WWW: http://www.ifad.dk
> ---------------------------------------------------------------
> 
>