Groups > comp.programming.threads > #1339

Re: condvars of ACE framwork - possible bug

Newsgroups	comp.programming.threads
Date	2013-02-06 20:30 -0800
References	(1 earlier) <a665fcf7-0bab-4207-b265-dc84a90c0d59@googlegroups.com> <a171fec1-2833-4c0b-a89e-f1d0b0d6876a@e10g2000vbv.googlegroups.com> <5ded78d9-8988-45aa-8de0-ccc4b702f7e8@googlegroups.com> <b2771477-2f19-412e-85e5-b30586c4f72c@fv9g2000vbb.googlegroups.com> <4e4762e3-fdf3-4c48-a928-5102961b32b4@googlegroups.com>
Message-ID	<ba029ea2-c7b4-44d8-aca7-e87a8be7e93e@x13g2000vby.googlegroups.com> (permalink)
Subject	Re: condvars of ACE framwork - possible bug
From	Michael Podolsky <michael.podolsky.69@gmail.com>

Show all headers | View raw

> I was looking for a correct-usage example, with a description of how ACE breaks the rules and thus breaks the correct-usage. I'm just having a hard time working backwards from the bug description :), eg: "this code should work, but it doesn't when using ACE because...".

I see. So, taking your code (with my marks) as a starting point:

Thread A:
--------------------
m.lock
predicate=true
c.signal
m.unlock
...
m.lock
while (predicate)     // line L3
  c.wait(m)               // line L2
m.unlock

Thread B:
--------------------
m.lock
while (!predicate)
  c.wait(m)                     // line L1
predicate=false
c.signal
m.unlock

Let first thread B run and arrive to the execution of wait on line L1,
and inside the ACE implementation of B let it be preempted right here
on the  line 2:

line 1:       ACE_OS::mutex_unlock (external_mutex);
line 2:        /* here we are preempted */
line 3:       result = ACE_OS::sema_wait (&cv->sema_);

You should see, we just released the  external_mutex and did not yet
start to wait on the semaphore  cv->sema_.

Now thread A starts to run, it locks mutex, sets predicate to true, it
signalls condvar (internally signalling cv->sema_), it unlocks the
mutex, it locks the mutex again, it executes wait on line L2 and it
succeeds with it because internal semaphore is signalled (just by the
same thread A). Well, then it retests the condition on line L3 and
waits again on L2.

Now thread B finally approaches line 3 and starts to wait on cv-
>sema_. This wait will never end because the signal from thread A was
eaten up. The signal is lost.

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

condvars of ACE framwork - possible bug Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-04 22:38 -0800
  Re: condvars of ACE framwork - possible bug Codeplug <graham.greene@charter.net> - 2013-02-06 13:42 -0800
    Re: condvars of ACE framwork - possible bug Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-06 18:36 -0800
      Re: condvars of ACE framwork - possible bug Codeplug <graham.greene@charter.net> - 2013-02-06 19:39 -0800
        Re: condvars of ACE framwork - possible bug Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-06 20:01 -0800
          Re: condvars of ACE framwork - possible bug Codeplug <graham.greene@charter.net> - 2013-02-06 20:16 -0800
            Re: condvars of ACE framwork - possible bug Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-06 20:30 -0800
              Re: condvars of ACE framwork - possible bug Codeplug <graham.greene@charter.net> - 2013-02-07 09:05 -0800
                Re: condvars of ACE framwork - possible bug Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-07 19:27 -0800
  Re: condvars of ACE framwork - possible bug Noob <root@127.0.0.1> - 2013-02-07 11:54 +0100
    Re: condvars of ACE framwork - possible bug Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-07 19:24 -0800

csiph-web