[omniORB] omni_semaphore operation?

[Jean Francois Poilpret]

Hi Dietmar,

In fact, you missed the point that in omni_semaphore code, c is a =
condition variable (omni_condition).
c is "associated" with omni_mutex m, which means that whenever you call =
c.wait(), l is unlocked at the beginning of wait(), and locked backed at =
the time wait() returns (this is the way condition variables are used).

So if you call omni_semaphore::wait() from thread 1, it will be blocked =
in c.wait(), with no lock on omni_mutex l. Then if from thread 2, you =
call post() the post will lock l to increment value, the will release =
the lock, then will signal on c, which means that the c.wait() from =
thread 1 will be awakened (and at this time, l will be locked again).

Is this clearer ?

In fact, usage of condition variables is not so obvious when you're not =
used to them !

Hope this helps

Regards,

    Jean-Francois


-----Original Message-----
From: Dietmar May <dcmay@object-workshops.com>
To: omniorb-list@uk.research.att.com <omniorb-list@uk.research.att.com>
Date: vendredi 11 ao=FBt 2000 07:18
Subject: [omniORB] omni_semaphore operation?


Hi all,

I must be missing something obvious (or maybe NOT so obvious).

The omni_semaphore code for 2.8.0 contains:

void
omni_semaphore::wait(void)
{
    omni_mutex_lock l(m);

    while (value =3D=3D 0)
        c.wait();

    value--;
}

void
omni_semaphore::post(void)
{
    {
        omni_mutex_lock l(m);
        value++;
    }

    c.signal();
}

Now, if wait() is called in thread 1, the mutex 'm' gets locked by =
thread 1. Now when post() is called by thread 2, it also attempts to =
lock 'm'. However, since 'm' is already locked by thread 1, the threads =
would seem to deadlock, since thread 1 will not release 'm' until after =
signal() is called by thread 2 -- but thread 2 is blocked waiting for =
'm', and cannot reach the call to signal().

Or so it seems at first glance.

What am I missing?

Thanks,
Dietmar