[omniORB] Condition varaibles - follow up...

[Shinji Suzuki]

Ole,

Forgive me if I'm wrong, I think wait() will relinquishes the
mutex acquired by omni_mutex_lock::omni_mutex_lock. With that
said, sharing a mutex among multiple cond-var may not be
something you are allowed to do.

-shinji

> Message-Id: <36A7152A.55A3AF6F@ifad.dk>
> Date: Thu, 21 Jan 1999 12:53:14 +0100
> From: Ole Storm <storm@ifad.dk>
> Organization: IFAD
> X-Mailer: Mozilla 4.5 [en] (WinNT; I)
> X-Accept-Language: en
> Mime-Version: 1.0
> To: Shinji Suzuki <suzuki@wni.co.jp>
> Cc: "omniorb-list@orl.co.uk" <omniorb-list@orl.co.uk>
> Subject: Re: [omniORB] Condition varaibles - follow up...
> Content-Transfer-Encoding: 7bit
> 
> Hi Shinji,
> 
> Shinji Suzuki wrote:
> > (...)
> > you may have to do
> > 
> > BufferItem
> > Buffer_i::GetItem()
> > {
> >    omni_mutex_lock l(omni_mutex_cond_mutex); // safer this way than m.lock()
> >    while( !index ) {
> >     // No items awailable. Wait on the condition varaible empty_buf:
> >      empty_buf.wait();
> >    }
> >    BufferItem itm = TheBuffer[--index];
> >    cout << "Returned item: " << item << "\n" << flush
> >    // Signal one of the possible waiting threads on PutItem()
> >    full_buf.signal();
> >    return itm;
> > }
> > 
> > and apply similar changes elsewhere.
> 
> 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
> ---------------------------------------------------------------
>