Home Patches

patch #3 for Ice 3.2: Fix for condition variable implementation under Windows.

matthewmatthew NL, CanadaMember Matthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications Engine ✭✭✭
This patch fixes a bug with IceUtil::Cond under Windows which could cause a deadlock if signal was used in conjunction multiple waiting threads where at least one thread is using timedWait. Note that this bug also affects IceUtil::Monitor since this uses IceUtil::Cond.

This bug was originally reported in this thread: http://www.zeroc.com/forums/bug-reports/3198-monitor-util-thread-block-windows-system.html#post14089

The patch is fully binary compatible with Ice 3.2. Note that this is a Windows problem only, Unix platforms are not affected. To apply the patch to a fresh Ice 3.2 source distribution:
  C:\> cd Ice-3.2.0
  C:\Ice-3.2.0> patch -p0 < patch.txt


  • Matt NassrMatt Nassr Member Matthew NassrOrganization: Argon STProject: Audio Middleware
    I'm curious about what this patch fixes because I am getting the same problem with the patched version (it looks like the patch is merged into all versions of Ice after 3.2.0) of Cond.cpp.

    To be specific, I have multiple waiting threads (one of them on a timedWait), and the deadlock occurs in the postWait method on the _queue.wait() semaphore call. This comment, which is part of the patch, is above the wait statement:

    // Consume the queue post to prevent spurious wakeup. Note
    // that although the internal mutex could be released
    // prior to this wait() call, doing so gains nothing since
    // this wait() MUST return immediately (if it does not
    // there is a major bug and the entire application will
    // deadlock).


    It appears that this wait() is not returning immediately and there is a 'major bug' since the 'entire application deadlocks'. I am trying to trace when this _queue semaphore is supposed to be posted to figure out why this is not happening and the consumption comes up empty.

    I would like to know why this patch is only applicable to Windows, since that would shed light on what is actually going on here. I have made a workaround in my code by spacing the waiting threads out with small sleep statements, but this is obviously non-ideal. I imagine a code example would help, but this is inside a very large application. I could go about creating one, but I would like to know a little bit more about this patch first.

  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Matt,

    This was a patch for our implementation of condition variables on Windows. Other platforms (Linux, Mac OS X, Solaris...) have native condition variables, so there is no need to implement condition variables there.

    When you wait on a condition variable, blocking is expected. We use this condition variable implementation frequently, and while a bug is always possible, it sounds unlikely.

    If you can get the stack of all active threads when this deadlock occurs, it could help pinpoint the exact issue.

    Best regards,
  • Matt NassrMatt Nassr Member Matthew NassrOrganization: Argon STProject: Audio Middleware
    Bernard, thank you for your quick response. As it turned out, the hang in Ice was due to memory corruption elsewhere in the program, there is nothing I can find wrong with the CV implementation.

Sign In or Register to comment.