Here's an idea on how to test this:

1) Make AtomicFlag's constructor constexpr.

2)

namespace base {

namespace {

AtomicFlag g_complete_initialization;
AtomicFlag g_constructor_called;

}

class LazilyInstantiated {
 public:
  LazilyInstantiated() {
    ASSERT_FALSE(g_constructor_called.IsSet());
    g_constructor_called.Set();
    while (!g_complete_initialization.IsSet())
      PlatformThread::YieldCurrentThread();
  }

  ~LazilyInstantiated() {
    g_constructor_called.UnsafeResetForTesting();
    g_complete_initialization.UnsafeResetForTesting();
  }
}

LazyInstance<LazilyInstantiated>::DestructorAtExit g_lazily_instantiated;

}  // namespace

TEST(...) {

1) Post a TaskPriority::BACKGROUND task that calls g_lazily_instantiated.Get()
2) Post a bunch of TaskPriority::USER_VISIBLE tasks that wait for g_constructor_called.IsSet() and then call g_lazily_instantiated.Get() -- and therefore get stuck blocking on the construction.
3) Wait a bit on main thread and call g_complete_initialization.Set().

Associate a BarrierClosure to the above tasks to be invoked after the obtain the LazyInstance. Block here until the BarrierClosure resolves (e.g. on a WaitableEvent which is unblocked when it resolves).
This will hang if any of the foreground tasks hangs trying to get the LazyInstance.

}

}  // namespace base


Happy to review, thanks!

@bruce: any chance you can generate this test case? would be great to have on trunk before merging to M64 for  issue 797129 

Actually, I'll take a stab at this right away given the need-for-speed to get on M64.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/70b37302be21346d0b8315d254939ae81105da28

commit 70b37302be21346d0b8315d254939ae81105da28
Author: Gabriel Charette <gab@chromium.org>
Date: Wed Jan 17 21:00:18 2018

Add LazyInstanceTest.PriorityInversionAtInitializationResolves

This test ensures that LazyInstance initialization isn't blocked
by priority inversions when mixed-priority threads try to
initialize the same LazyInstance object. That is, test to make
sure r527445 works.

On my Z840, this test takes 5 to 10 seconds to complete without
r527445 but ~30ms with it :). An explicit 5s timeout was added to
this test to make the regression case indeed fail (instead of
relying on the longer test timeout under which it's mostly fine).

Bug:  799853 ,  797129 
Change-Id: I3ff59b92f0b4c15574f091549b3cfe8eadd9ae6f
Reviewed-on: https://chromium-review.googlesource.com/866871
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529886}
[modify] https://crrev.com/70b37302be21346d0b8315d254939ae81105da28/base/lazy_instance_unittest.cc

[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.

This is the test end, no merge needed.