Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #1341

Re: condvars of ACE framwork - possible bug

Show all headers | View raw

On Wednesday, February 6, 2013 11:30:24 PM UTC-5, Michael Podolsky wrote:
> > 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.

I agree with your analysis. Under Posix semantics, a signal() should only ever release a thread that is currently blocked in a wait(). In this case, a wait() is being satisfied by a prior call to signal() in the same thread - oops.

gg

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