[cfe-commits] patch: libcxxabi cxa_*_virtual and cxa_guard_* methods

[Nick Lewycky]

On 21 May 2011 17:05, John McCall <rjmccall at apple.com> wrote:

> On May 19, 2011, at 11:11 PM, Nick Lewycky wrote:
> > I've started dipping my toes in the libcxxabi project by implementing a
> few simple methods. Patch attached, please review!
> >
> > This isn't heavily tested, I'm mostly just trying to make sure I have the
> style down. Please let me know if we should be using different file names
> (hard to follow a pattern where there isn't one), of if the private methods
> in cxa_guard actually belong in an anonymous namespace, etc.
>
> Guard variables need to support recursive initialization:  the
> initialization
> of one variable must be able to kick off arbitrary code that might perform
> its own initialization.


Okay, I can handle that. I wrote a test for it:

namespace test3 {
    int helper1(int i) {
        if (i == 0)
            return 0;
        static int j = 0 helper1(i - 1);
        return j + 1;
    }
    void test() {
        static int x = helper1(10);
    }
}

and discovered that libstdc++ doesn't support it. They detect the recursive
initialization and throw an exception.

In C++11, there's a guarantee that this won't deadlock
> even if the first initialization blocks on a different thread.
>

Hold up, what does this actually mean? Given:

  int test_a(int x) {
    if (x == 0)
      return 0;
    static int A = test_b(x - 1);
    return A + 1;
  }
  int test_b(int x) {
    if (x == 0)
      return 0;
    static int B = test_a(x - 1);
    return B + 1;
  }

suppose that thread 1 enters test_a(10) and grabs the lock on A at the same
time that thread 2 enters test_b(10) and grabs the lock on B. The deadlock
is avoided how?

Probably the most reasonable way to handle this is to have a global lock
> which is *not* held during initialization, and a global condition variable
> that threads wait on if they're waiting for somebody else to perform an
> initialization.
>

It's not clear to me what you're proposing, but I strongly want to avoid
anything that blocks the other threads from running their own initializers
in parallel for as long as they're independent. I think I'll understand your
proposal once I understand the constraints you mentioned above.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110522/a238c2ec/attachment.html>